From gnu_andrew at member.fsf.org Tue Sep 1 02:45:09 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 1 Sep 2009 10:45:09 +0100 Subject: PING 1: [PATCH FOR REVIEW]: Sync HOTSPOT_INTERPRETER_MODE usage between CORBA and JDK Message-ID: <17c6771e0909010245o60b6bb82h516b4c34198694d@mail.gmail.com> 2009/8/27 Andrew John Hughes : > The patch ?http://cr.openjdk.java.net/~andrew/ecj/02/webrev.02/ syncs > the CORBA Defs-java.gmk to match the JDK version. ?The javac changes > have already been approved by Jonathon (see below). ?Does the addition > to support USE_HOTSPOT_INTERPRETER_MODE look ok? ?If so, I'll push the > patch. > > Thanks. > > ---------- Forwarded message ---------- > From: Jonathan Gibbons > Date: 2009/8/27 > Subject: Re: [PATCH FOR REVIEW]: Make source/target options explicit > for CORBA bootstrap tools > To: Andrew John Hughes > Cc: build-dev at openjdk.java.net > > > > On Aug 27, 2009, at 3:53 AM, Andrew John Hughes wrote: > >> 2009/8/20 Andrew John Hughes : >>> >>> 2009/8/20 Jonathan Gibbons : >>>> >>>> Andrew John Hughes wrote: >>>> >>>> 2009/8/18 Andrew John Hughes : >>>> >>>> >>>> 2009/8/18 Jonathan Gibbons : >>>> >>>> >>>> Andrew, >>>> >>>> If this is a patch for jdk7, it does not appear to be a patch to a recent >>>> copy >>>> of 7. >>>> >>>> >>>> It's against b69 which is the latest release (from Friday). ?The >>>> patches are against the IcedTea forest so builds can be tested with >>>> IcedTea as well. >>>> >>>> Specifically, you do not seem to have the recent changeset ?to set >>>> >>>> >>>> the source/target used to compile JDK to 7. [1] >>>> >>>> >>>> >>>> Er... yes I do: >>>> >>>> # Add the source level >>>> LANGUAGE_VERSION = -source 7 >>>> JAVACFLAGS ?+= $(LANGUAGE_VERSION) >>>> >>>> # Add the class version we want >>>> TARGET_CLASS_VERSION = 7 >>>> CLASS_VERSION = -target $(TARGET_CLASS_VERSION) >>>> JAVACFLAGS ?+= $(CLASS_VERSION) >>>> JAVACFLAGS ?+= -encoding ascii >>>> JAVACFLAGS ?+= -classpath $(BOOTDIR)/lib/tools.jar >>>> JAVACFLAGS ?+= $(OTHER_JAVACFLAGS) >>>> >>>> but these only cover the rt classes and not the bootstrap classes. >>>> >>>> >>>> >>>> While your patch does not directly conflict with any edits in that patch, >>>> and >>>> while the effect of your patch looks OK, in that patch I was extending the >>>> precedent of TARGET_CLASS_VERSION to have an explicit macro for >>>> (just) the version number, so that it is easy to change the value of (just) >>>> the version number from the command line. >>>> >>>> With that in mind, I would suggest something like the following for your >>>> patch: >>>> >>>> BOOT_SOURCE_LANGUAGE_VERSION = 6 >>>> BOOT_TARGET_CLASS_VERSION = 6 >>>> BOOT_JAVACFLAGS ?+= -encoding ascii -source $(BOOT_SOURCE_LANGUAGE_VERSION) >>>> -target $(BOOT_TARGET_CLASS_VERSION) >>>> >>>> >>>> >>>> I didn't copy this for the 6 changes because I didn't immediately see >>>> the point of using variables just for this single use. ?I forgot that >>>> it is possible to override these from the command line, so I've update >>>> the patch: >>>> >>>> http://cr.openjdk.java.net/~andrew/ecj/02/webrev.02/ >>>> >>>> >>>> >>>> -- Jon >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/compiler-dev/2009-July/001286.html >>>> >>>> >>>> On Aug 18, 2009, at 5:24 AM, Andrew John Hughes wrote: >>>> >>>> >>>> >>>> Currently the javac calls for building the bootstrap tools (not the >>>> classes for the final JDK, which correctly now use source and target >>>> 7) don't set an explicit source and target version. >>>> >>>> The webrev: >>>> >>>> http://cr.openjdk.java.net/~andrew/ecj/02/webrev.01/ >>>> >>>> sets these to 6 explicitly, as happens in the Ant builds performed by >>>> langtools/jaxp/jaxws. ?This is noticeable especially when using ecj as >>>> the bootstrap javac as it defaults to a version < 1.5, and the build >>>> fails. >>>> >>>> Ok to push? >>>> >>>> Thanks, >>>> -- >>>> Andrew :-) >>>> >>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> Support Free Java! >>>> Contribute to GNU Classpath and the OpenJDK >>>> http://www.gnu.org/software/classpath >>>> http://openjdk.java.net >>>> >>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>> >>>> >>>> >>>> >>>> -- >>>> Andrew :-) >>>> >>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> Support Free Java! >>>> Contribute to GNU Classpath and the OpenJDK >>>> http://www.gnu.org/software/classpath >>>> http://openjdk.java.net >>>> >>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>> >>>> >>>> >>>> Is this version now ok? ?If so, I'll push it to the build gate using >>>> the bug ID Kelly allocated for the same fix in JDK. >>>> >>>> >>>> Andrew, >>>> >>>> I approve your webrev http://cr.openjdk.java.net/~andrew/ecj/02/webrev.02/ >>> >>> Thanks. ?Pushed this last night: >>> http://hg.openjdk.java.net/jdk7/build/corba/rev/8001ba2bf10d >>> >>>> My earlier confusion was caused by the fact that the corba Makefile is not >>>> consistent with the jdk Makefile with respect to the use of >>>> SOURCE_LANGUAGE_VERSION. >>>> It would be good to (separately) fix that inconsistency, but that does not >>>> affect the validity of what you propose here. >>>> >>> >>> Yes, I see what you mean now. ?Here's another webrev: >>> >>> http://cr.openjdk.java.net/~andrew/consistency/01/webrev.01/ >>> >>> which should make the two fairly consistent. ?It brings in a lot of >>> changes to the version in JDK that seem to have been missed from >>> CORBA, namely: >>> >>> ?* Turning off option outputs on fastdebug builds >>> ?* Supporting USE_HOTSPOT_INTERPRETER_MODE >>> ?* Supporting JAVAC_MAX_WARNINGS and JAVAC_WARNINGS_FATAL >>> ?* The SOURCE_LANGUAGE_VERSION sync above >>> ?* Include JAR_JFLAGS in BOOT_JAR_JFLAGS >>> >>> The following differences remain, which didn't seem appropriate to include: >>> >>> -JAVACFLAGS ?+= -classpath $(BOOTDIR)/lib/tools.jar >>> +JAVACFLAGS ?+= "-Xbootclasspath:$(CLASSBINDIR)" >>> ?JAVACFLAGS ?+= $(OTHER_JAVACFLAGS) >>> >>> ?# Needed for javah >>> -JAVAHFLAGS += -classpath $(CLASSBINDIR) >>> +JAVAHFLAGS += -bootclasspath $(CLASSBINDIR) >>> >>> I wasn't sure of the pros/cons of these changes but can easy add them if needed. >>> >>>> -- Jon >>>> >>> >>> >>> >>> -- >>> Andrew :-) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>> >> >> Does this change look ok? Can I push it? >> >> Thanks, >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > > Andrew, > > The changes regarding flags for javac look OK. ?I can't speak to the > Hotspot options. > > -- Jon > > > > > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > Ping? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Tue Sep 1 03:01:30 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 1 Sep 2009 11:01:30 +0100 Subject: PING 2: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti Message-ID: <17c6771e0909010301q12b43068p14996edfb5c38aa3@mail.gmail.com> 2009/8/24 Andrew John Hughes : > 2009/8/22 Andrew John Hughes : >> 2009/8/22 David Schlosnagle : >>> Andrew, >>> >>> I'm just a beginner here trying to get a better understanding of the JDK by >>> scanning code reviews and I have a comment on the changes in >>> . >>> >>> In all the sa.make files (Linux, Solaris & Windows), should the -g flag be >>> removed from the two modified lines since it's included in the >>> SA_JAVAC_FLAGS via JAVAC_FLAGS in defs.make? I'd assume that the duplicate >>> -g won't cause failures, but it seems to force all debug info to always be >>> included even if one tried to override the compile flags to disable or alter >>> the debug information included. >>> >>> Thanks, >>> David Schlosnagle >>> >> >> Well spotted! They should have been removed. ?Revised in >> http://cr.openjdk.java.net/~andrew/ecj/03/webrev.04 >> >>> >>> On Thu, Aug 20, 2009 at 8:22 AM, Andrew John Hughes >>> wrote: >>>> >>>> 2009/8/20 John Coomes : >>>> > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: >>>> >> 2009/8/18 John Coomes : >>>> >> > Daniel D. Daugherty (Daniel.Daugherty at Sun.COM) wrote: >>>> >> >> Andrew, >>>> >> >> >>>> >> >> A couple of comments: >>>> >> >> >>>> >> >> - if you specify '-source 6', then '-target 6' is implied >>>> >> >> ?? so you don't really need both >>>> >> >> - I would prefer to see a top-level macro that defines the >>>> >> >> ?? bootstrap tools javac option and then have the various >>>> >> >> ?? Makefiles use that macro. Something in make/defs.make: >>>> >> >> >>>> >> >> ?? ?? ?? BOOTSTRAP_TOOLS.JAVAC.FLAGS="-source 6" >>>> >> >> >>>> >> >> ?? or something like that. >>>> >> > >>>> >> > +1 on the top-level macro. ??In HotSpot, I would call it JAVAC_FLAGS >>>> >> > or >>>> >> > COMPILE_JAVAC_FLAGS, and add it to the COMPILE.JAVAC macro (spelled >>>> >> > COMPILE_JAVAC on windows) so that every compilation uses it. ??Then >>>> >> > fewer places need to be touched. >>>> >> > >>>> >> > Also, please leave the default value empty. ??On platforms that need >>>> >> > it, it can be set on the command line or in the environment. >>>> >> > Specifying a value requires periodic maintenance. ??Yes, the period >>>> >> > is >>>> >> > long, but it's a pain when the build breaks because of some stale >>>> >> > value in a makefile. >>>> >> > >>>> >> >>>> >> Ok, here's the changeset I was working on before I received your mail >>>> >> and which I've since successfully tested with hotspot-rt: >>>> >> >>>> >> http://cr.openjdk.java.net/~andrew/ecj/03/webrev.02/ >>>> > >>>> > I submitted your patch to the build queue; it will take several hours, >>>> > there's one job ahead of it. >>>> > >>>> > After looking at it again, the include of make/defs.make in >>>> > make/windows/makefiles/rules.make will most likely fail to build. ?The >>>> > latter is a windows nmake file, so the gnu-specific syntax will be >>>> > rejected and there are other unixisms in there (e.g., shell until). >>>> > >>>> >>>> I had a feeling Windows would be the one to bite... >>>> >>>> > Instead, try updating MAKE_ARGS in make/defs.make, I believe those are >>>> > exported to sub-makes. ?Since it has to be portable, I believe you'll >>>> > have to use '_' instead of '.' in the macro name. >>>> > >>>> >>>> Ok, in http://cr.openjdk.java.net/~andrew/ecj/03/webrev.03/ I've >>>> reverted the addtion >>>> of defs.make in favour of using MAKE_ARGS and renamed the variables >>>> using underscores (which I prefer anyway). >>>> >>>> Where I am confused is how the MAKE_ARGS changes get through to the >>>> Windows build if it doesn't parse defs.make. >>>> makefiles/windows/defs.make seems to imply that the top-level one will >>>> be read. >>>> >>>> >> This defines the variables in the top-level defs.make file. ?The >>>> >> versions are stored separately, in the same way as they are in the >>>> >> JDK: >>>> >> >>>> >> http://hg.openjdk.java.net/jdk7/build/jdk/rev/80368890a2a0 >>>> >> >>>> >> SA is still done separately as it's currently 1.4. ?The default for >>>> >> others is 6. >>>> >> The rest of the patch ensures this makefile is picked up and its >>>> >> values used for compilation across all three platforms. >>>> >> >>>> >> This is added to the invocations rather than COMPILE.JAVAC. ?As you >>>> >> imply in your mail, this value varies between platforms and even >>>> >> within the same platform. ?Just the GNU/Linux port itself defines it >>>> >> in about four ways. >>>> > >>>> > Take a look, it's simply selecting which path to use. ?After the def >>>> > of COMPILE.JAVAC, a simple >>>> > >>>> > ? ? ? ?COMPILE.JAVAC += $(BOOTSTRAP_JAVAC.FLAGS) >>>> > >>>> > should do it. ?Windows will have to be different, though. >>>> > >>>> >>>> Yes, the other problem is this forces the same options to SA as well >>>> which uses COMPILE.JAVAC. ?To keep the current status quo (at least >>>> for now), these need a different set of flags. >>>> >>>> >> I don't agree with leaving the value blank. ?The issue is relevant on >>>> >> all platforms, as leaving it blank makes the build open to whatever >>>> >> the default value is of the bootstrap JDK. ?For instance, this just >>>> >> changed to 7 with OpenJDK, so current builds will produce 1.7 bytecode >>>> >> while builds using an older OpenJDK7 or OpenJDK6 will use 6. ?From >>>> >> personal experience, it's much harder to debug a problem when you have >>>> >> to take into account the boot JDK being used, which may vary, than >>>> >> when you have an explicit value. >>>> >> >>>> >> It seems much clearer to specify it explicitly in one common place for >>>> >> all platforms, which can also be easily overridden from the command >>>> >> line if needed. ?This is the same as is now done for JDK, langtools, >>>> >> jaxp and jaxws and will shortly be the case in corba. >>>> > >>>> > The jdk, langtools, etc., repos are much more sensitive to this >>>> > setting than hotspot, which uses it only for makedeps and jvmti header >>>> > generation. ?It's non-critical, and I think it's safe to assume that >>>> > the default class file version produced by a boot jdk can also be run >>>> > by that same boot jdk. >>>> > >>>> > So far, ecj is the only known boot env needing this set explicitly. >>>> > >>>> >>>> That kind of assumption is the thing that tends to come back and bite >>>> you. ?It's especially true because: >>>> >>>> ?* The boot JDK is something determined on a per-user basis, so just >>>> updating the system JDK may cause a failure that's hard to diagnose. >>>> ?* Failures in HotSpot javac builds are already hard to diagnose >>>> because it doesn't print out the javac invocation. ?It took me longer >>>> to track this down than the equivalents in JDK and CORBA, and I've >>>> been working with the OpenJDK build for about two years now. >>>> >>>> Yes, ecj is the only one that fails. ?But we now have at least two >>>> JDKs that will produce different results: OpenJDK6 (which defaults to >>>> 6) and OpenJDK7 (which defaults to 7). ?There are even more if you >>>> include the proprietary JDKs and JDK 1.5 which I assume can also build >>>> OpenJDK at a push. >>>> >>>> One of the side effects of releasing code to the world is that people >>>> are going to try and run into all sorts of corner cases. ?Assuming the >>>> defaults are good works fine when the only people building the code >>>> are Sun developers, but this is no longer true and something like this >>>> is just the kind of thing a casual builder of the code will run into >>>> and wonder why it fails. >>>> >>>> I agree this code is less used than the equivalent JDK and CORBA code, >>>> but surely it's better to be as consistent as possible across the >>>> codebase? >>>> >>>> Finally, switching SA to use the defaults would be a visible change. >>>> >>>> > -John >>>> > >>>> >> >> Which repo are you targeting for this change? >>>> >> > >>>> >> > I'd suggest hotspot-rt. >>>> >> > >>>> >> > Note that all hotspot changes have to be built on all platforms >>>> >> > before >>>> >> > being pushed; we have an automated system called jprt that does >>>> >> > builds >>>> >> > and tests on the various platforms. ??Unfortunately, it isn't >>>> >> > available >>>> >> > externally. ??Sync up with the latest hotspot-rt and then contact me >>>> >> > privately with a patch or your repo location and I'll run it through. >>>> >> > >>>> >> >>>> >> The patch from this webrev is against hotspot-rt so can be tested. >>>> >> >>>> >> >> Yes, I see that SA uses '-source 1.4' in each platform makefile. >>>> >> >> That should be fixed also, but that's another issue... >>>> >> > >>>> >> > Sigh. ??Stale values in makefiles ... >>>> >> > >>>> >> >>>> >> Also fixed now by this patch. ?At least 1.4 is in one common makefile >>>> >> rather than occurring six times over three makefiles... :) >>>> >> >>>> >> > -John >>>> >> > >>>> >> >> > Andrew John Hughes wrote: >>>> >> >> > The makeDeps and jvmti bootstrap tools are built without explicit >>>> >> >> > source and target options. >>>> >> >> > >>>> >> >> > This webrev: >>>> >> >> > >>>> >> >> > http://cr.openjdk.java.net/~andrew/ecj/03/webrev.01/ >>>> >> >> > >>>> >> >> > sets them to 6 explicitly. The change has to be replicated three >>>> >> >> > times, because for some reason, the javac invocations are in >>>> >> >> > platform-specific makefiles. ??I've tested the change successfully >>>> >> >> > on >>>> >> >> > GNU/Linux, where it allows ecj to be used as javac. ??ecj defaults >>>> >> >> > to >>>> >> >> > <1.5 and thus otherwise fails to build. ??I've assumed that the >>>> >> >> > same >>>> >> >> > changes are applicable for Solaris and Windows, and that the >>>> >> >> > source >>>> >> >> > and target options don't have to be written in Latin or something >>>> >> >> > to >>>> >> >> > work on these platforms. >>>> >> >> > >>>> >> >> > Is this ok to push? >>>> >> >> > >>>> >> >> > Thanks, >>>> >> >> > >>>> >> > >>>> >> > >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Andrew :-) >>>> >> >>>> >> Free Java Software Engineer >>>> >> Red Hat, Inc. (http://www.redhat.com) >>>> >> >>>> >> Support Free Java! >>>> >> Contribute to GNU Classpath and the OpenJDK >>>> >> http://www.gnu.org/software/classpath >>>> >> http://openjdk.java.net >>>> >> >>>> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>> >> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>> > >>>> > >>>> >>>> >>>> >>>> -- >>>> Andrew :-) >>>> >>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> Support Free Java! >>>> Contribute to GNU Classpath and the OpenJDK >>>> http://www.gnu.org/software/classpath >>>> http://openjdk.java.net >>>> >>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>> >>> >> >> >> >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >> > > > Is this now ok to push? It passed the build. > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > Ping? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Thomas.Rodriguez at Sun.COM Tue Sep 1 11:37:24 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 01 Sep 2009 11:37:24 -0700 Subject: PING 1: [PATCH FOR REVIEW]: Sync HOTSPOT_INTERPRETER_MODE usage between CORBA and JDK In-Reply-To: <17c6771e0909010245o60b6bb82h516b4c34198694d@mail.gmail.com> References: <17c6771e0909010245o60b6bb82h516b4c34198694d@mail.gmail.com> Message-ID: <89710453-0F87-458D-8498-A27183F77A0C@sun.com> Why are you asking for feedback on a corba build change on hotspot- dev? Shouldn't this be in build-dev or the corba alias? tom On Sep 1, 2009, at 2:45 AM, Andrew John Hughes wrote: > 2009/8/27 Andrew John Hughes : >> The patch http://cr.openjdk.java.net/~andrew/ecj/02/webrev.02/ syncs >> the CORBA Defs-java.gmk to match the JDK version. The javac changes >> have already been approved by Jonathon (see below). Does the >> addition >> to support USE_HOTSPOT_INTERPRETER_MODE look ok? If so, I'll push >> the >> patch. >> >> Thanks. >> >> ---------- Forwarded message ---------- >> From: Jonathan Gibbons >> Date: 2009/8/27 >> Subject: Re: [PATCH FOR REVIEW]: Make source/target options explicit >> for CORBA bootstrap tools >> To: Andrew John Hughes >> Cc: build-dev at openjdk.java.net >> >> >> >> On Aug 27, 2009, at 3:53 AM, Andrew John Hughes wrote: >> >>> 2009/8/20 Andrew John Hughes : >>>> >>>> 2009/8/20 Jonathan Gibbons : >>>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>> 2009/8/18 Andrew John Hughes : >>>>> >>>>> >>>>> 2009/8/18 Jonathan Gibbons : >>>>> >>>>> >>>>> Andrew, >>>>> >>>>> If this is a patch for jdk7, it does not appear to be a patch to >>>>> a recent >>>>> copy >>>>> of 7. >>>>> >>>>> >>>>> It's against b69 which is the latest release (from Friday). The >>>>> patches are against the IcedTea forest so builds can be tested >>>>> with >>>>> IcedTea as well. >>>>> >>>>> Specifically, you do not seem to have the recent changeset to set >>>>> >>>>> >>>>> the source/target used to compile JDK to 7. [1] >>>>> >>>>> >>>>> >>>>> Er... yes I do: >>>>> >>>>> # Add the source level >>>>> LANGUAGE_VERSION = -source 7 >>>>> JAVACFLAGS += $(LANGUAGE_VERSION) >>>>> >>>>> # Add the class version we want >>>>> TARGET_CLASS_VERSION = 7 >>>>> CLASS_VERSION = -target $(TARGET_CLASS_VERSION) >>>>> JAVACFLAGS += $(CLASS_VERSION) >>>>> JAVACFLAGS += -encoding ascii >>>>> JAVACFLAGS += -classpath $(BOOTDIR)/lib/tools.jar >>>>> JAVACFLAGS += $(OTHER_JAVACFLAGS) >>>>> >>>>> but these only cover the rt classes and not the bootstrap classes. >>>>> >>>>> >>>>> >>>>> While your patch does not directly conflict with any edits in >>>>> that patch, >>>>> and >>>>> while the effect of your patch looks OK, in that patch I was >>>>> extending the >>>>> precedent of TARGET_CLASS_VERSION to have an explicit macro for >>>>> (just) the version number, so that it is easy to change the >>>>> value of (just) >>>>> the version number from the command line. >>>>> >>>>> With that in mind, I would suggest something like the following >>>>> for your >>>>> patch: >>>>> >>>>> BOOT_SOURCE_LANGUAGE_VERSION = 6 >>>>> BOOT_TARGET_CLASS_VERSION = 6 >>>>> BOOT_JAVACFLAGS += -encoding ascii -source $ >>>>> (BOOT_SOURCE_LANGUAGE_VERSION) >>>>> -target $(BOOT_TARGET_CLASS_VERSION) >>>>> >>>>> >>>>> >>>>> I didn't copy this for the 6 changes because I didn't >>>>> immediately see >>>>> the point of using variables just for this single use. I forgot >>>>> that >>>>> it is possible to override these from the command line, so I've >>>>> update >>>>> the patch: >>>>> >>>>> http://cr.openjdk.java.net/~andrew/ecj/02/webrev.02/ >>>>> >>>>> >>>>> >>>>> -- Jon >>>>> >>>>> [1] >>>>> http://mail.openjdk.java.net/pipermail/compiler-dev/2009-July/001286.html >>>>> >>>>> >>>>> On Aug 18, 2009, at 5:24 AM, Andrew John Hughes wrote: >>>>> >>>>> >>>>> >>>>> Currently the javac calls for building the bootstrap tools (not >>>>> the >>>>> classes for the final JDK, which correctly now use source and >>>>> target >>>>> 7) don't set an explicit source and target version. >>>>> >>>>> The webrev: >>>>> >>>>> http://cr.openjdk.java.net/~andrew/ecj/02/webrev.01/ >>>>> >>>>> sets these to 6 explicitly, as happens in the Ant builds >>>>> performed by >>>>> langtools/jaxp/jaxws. This is noticeable especially when using >>>>> ecj as >>>>> the bootstrap javac as it defaults to a version < 1.5, and the >>>>> build >>>>> fails. >>>>> >>>>> Ok to push? >>>>> >>>>> Thanks, >>>>> -- >>>>> Andrew :-) >>>>> >>>>> Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> Support Free Java! >>>>> Contribute to GNU Classpath and the OpenJDK >>>>> http://www.gnu.org/software/classpath >>>>> http://openjdk.java.net >>>>> >>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Andrew :-) >>>>> >>>>> Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> Support Free Java! >>>>> Contribute to GNU Classpath and the OpenJDK >>>>> http://www.gnu.org/software/classpath >>>>> http://openjdk.java.net >>>>> >>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>> >>>>> >>>>> >>>>> Is this version now ok? If so, I'll push it to the build gate >>>>> using >>>>> the bug ID Kelly allocated for the same fix in JDK. >>>>> >>>>> >>>>> Andrew, >>>>> >>>>> I approve your webrev http://cr.openjdk.java.net/~andrew/ecj/02/webrev.02/ >>>> >>>> Thanks. Pushed this last night: >>>> http://hg.openjdk.java.net/jdk7/build/corba/rev/8001ba2bf10d >>>> >>>>> My earlier confusion was caused by the fact that the corba >>>>> Makefile is not >>>>> consistent with the jdk Makefile with respect to the use of >>>>> SOURCE_LANGUAGE_VERSION. >>>>> It would be good to (separately) fix that inconsistency, but >>>>> that does not >>>>> affect the validity of what you propose here. >>>>> >>>> >>>> Yes, I see what you mean now. Here's another webrev: >>>> >>>> http://cr.openjdk.java.net/~andrew/consistency/01/webrev.01/ >>>> >>>> which should make the two fairly consistent. It brings in a lot of >>>> changes to the version in JDK that seem to have been missed from >>>> CORBA, namely: >>>> >>>> * Turning off option outputs on fastdebug builds >>>> * Supporting USE_HOTSPOT_INTERPRETER_MODE >>>> * Supporting JAVAC_MAX_WARNINGS and JAVAC_WARNINGS_FATAL >>>> * The SOURCE_LANGUAGE_VERSION sync above >>>> * Include JAR_JFLAGS in BOOT_JAR_JFLAGS >>>> >>>> The following differences remain, which didn't seem appropriate >>>> to include: >>>> >>>> -JAVACFLAGS += -classpath $(BOOTDIR)/lib/tools.jar >>>> +JAVACFLAGS += "-Xbootclasspath:$(CLASSBINDIR)" >>>> JAVACFLAGS += $(OTHER_JAVACFLAGS) >>>> >>>> # Needed for javah >>>> -JAVAHFLAGS += -classpath $(CLASSBINDIR) >>>> +JAVAHFLAGS += -bootclasspath $(CLASSBINDIR) >>>> >>>> I wasn't sure of the pros/cons of these changes but can easy add >>>> them if needed. >>>> >>>>> -- Jon >>>>> >>>> >>>> >>>> >>>> -- >>>> Andrew :-) >>>> >>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> Support Free Java! >>>> Contribute to GNU Classpath and the OpenJDK >>>> http://www.gnu.org/software/classpath >>>> http://openjdk.java.net >>>> >>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>> >>> >>> Does this change look ok? Can I push it? >>> >>> Thanks, >>> -- >>> Andrew :-) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> >> Andrew, >> >> The changes regarding flags for javac look OK. I can't speak to the >> Hotspot options. >> >> -- Jon >> >> >> >> >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> > > > Ping? > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Thomas.Rodriguez at Sun.COM Tue Sep 1 13:29:39 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 01 Sep 2009 13:29:39 -0700 Subject: [patch] Adding stack markings to the x86 assembly for not using executable stack In-Reply-To: <20090827162542.GJ10947@outflux.net> References: <4A96663B.1040109@ubuntu.com> <17c6771e0908270404t3554158cka2afe14cd636f572@mail.gmail.com> <20090827162542.GJ10947@outflux.net> Message-ID: >> Are you sending this patch upstream? It would be good to have some >> feedback from the HotSpot developers before we commit this for a >> release. >> >> Does this affect SPARC too? > > I'm not familiar with SPARC hardware, but if it supports "execute" > memory > protections, then it is a valuable change there too. It it doesn't, > it > won't hurt anything, IIUC. The machinery for this on Solaris is completely different. On Solaris it's done using mapfiles and it wouldn't be a bad idea to request non- executable stacks though this brings up a question about how all this interacts with shared libraries. If you have an executable that disables execute and it dlopens a library that doesn't, what happens? Presumably the executables and libraries have to be in agreement for this to really work, right? tom > > -Kees > > -- > Kees Cook > Ubuntu Security Team From gnu_andrew at member.fsf.org Tue Sep 1 14:33:28 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 1 Sep 2009 22:33:28 +0100 Subject: PING 1: [PATCH FOR REVIEW]: Sync HOTSPOT_INTERPRETER_MODE usage between CORBA and JDK In-Reply-To: <89710453-0F87-458D-8498-A27183F77A0C@sun.com> References: <17c6771e0909010245o60b6bb82h516b4c34198694d@mail.gmail.com> <89710453-0F87-458D-8498-A27183F77A0C@sun.com> Message-ID: <17c6771e0909011433s233bfd73t6115a669b97cc082@mail.gmail.com> 2009/9/1 Tom Rodriguez : > Why are you asking for feedback on a corba build change on hotspot-dev? > ?Shouldn't this be in build-dev or the corba alias? > As I explained in my original email and as demonstrated by the forwarded messages in the same mail (both below), the majority of changes in http://cr.openjdk.java.net/~andrew/consistency/01/webrev.01/ have already been approved. It was suggested that I ask the HotSpot team about the addition of USE_HOTSPOT_INTERPRETER_MODE to this Makefile (the same build machinery is already in the JDK makefile), as Jonathan didn't feel it his place to comment on these. If this addition looks ok, then I can commit the change. Specifically, the chunk is: +ifdef USE_HOTSPOT_INTERPRETER_MODE + JAVA_JVM_FLAGS += -Xint +endif > tom > > On Sep 1, 2009, at 2:45 AM, Andrew John Hughes wrote: > >> 2009/8/27 Andrew John Hughes : >>> >>> The patch ?http://cr.openjdk.java.net/~andrew/ecj/02/webrev.02/ syncs >>> the CORBA Defs-java.gmk to match the JDK version. ?The javac changes >>> have already been approved by Jonathon (see below). ?Does the addition >>> to support USE_HOTSPOT_INTERPRETER_MODE look ok? ?If so, I'll push the >>> patch. >>> >>> Thanks. >>> >>> ---------- Forwarded message ---------- >>> From: Jonathan Gibbons >>> Date: 2009/8/27 >>> Subject: Re: [PATCH FOR REVIEW]: Make source/target options explicit >>> for CORBA bootstrap tools >>> To: Andrew John Hughes >>> Cc: build-dev at openjdk.java.net >>> >>> >>> >>> On Aug 27, 2009, at 3:53 AM, Andrew John Hughes wrote: >>> >>>> 2009/8/20 Andrew John Hughes : >>>>> >>>>> 2009/8/20 Jonathan Gibbons : >>>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>> 2009/8/18 Andrew John Hughes : >>>>>> >>>>>> >>>>>> 2009/8/18 Jonathan Gibbons : >>>>>> >>>>>> >>>>>> Andrew, >>>>>> >>>>>> If this is a patch for jdk7, it does not appear to be a patch to a >>>>>> recent >>>>>> copy >>>>>> of 7. >>>>>> >>>>>> >>>>>> It's against b69 which is the latest release (from Friday). ?The >>>>>> patches are against the IcedTea forest so builds can be tested with >>>>>> IcedTea as well. >>>>>> >>>>>> Specifically, you do not seem to have the recent changeset ?to set >>>>>> >>>>>> >>>>>> the source/target used to compile JDK to 7. [1] >>>>>> >>>>>> >>>>>> >>>>>> Er... yes I do: >>>>>> >>>>>> # Add the source level >>>>>> LANGUAGE_VERSION = -source 7 >>>>>> JAVACFLAGS ?+= $(LANGUAGE_VERSION) >>>>>> >>>>>> # Add the class version we want >>>>>> TARGET_CLASS_VERSION = 7 >>>>>> CLASS_VERSION = -target $(TARGET_CLASS_VERSION) >>>>>> JAVACFLAGS ?+= $(CLASS_VERSION) >>>>>> JAVACFLAGS ?+= -encoding ascii >>>>>> JAVACFLAGS ?+= -classpath $(BOOTDIR)/lib/tools.jar >>>>>> JAVACFLAGS ?+= $(OTHER_JAVACFLAGS) >>>>>> >>>>>> but these only cover the rt classes and not the bootstrap classes. >>>>>> >>>>>> >>>>>> >>>>>> While your patch does not directly conflict with any edits in that >>>>>> patch, >>>>>> and >>>>>> while the effect of your patch looks OK, in that patch I was extending >>>>>> the >>>>>> precedent of TARGET_CLASS_VERSION to have an explicit macro for >>>>>> (just) the version number, so that it is easy to change the value of >>>>>> (just) >>>>>> the version number from the command line. >>>>>> >>>>>> With that in mind, I would suggest something like the following for >>>>>> your >>>>>> patch: >>>>>> >>>>>> BOOT_SOURCE_LANGUAGE_VERSION = 6 >>>>>> BOOT_TARGET_CLASS_VERSION = 6 >>>>>> BOOT_JAVACFLAGS ?+= -encoding ascii -source >>>>>> $(BOOT_SOURCE_LANGUAGE_VERSION) >>>>>> -target $(BOOT_TARGET_CLASS_VERSION) >>>>>> >>>>>> >>>>>> >>>>>> I didn't copy this for the 6 changes because I didn't immediately see >>>>>> the point of using variables just for this single use. ?I forgot that >>>>>> it is possible to override these from the command line, so I've update >>>>>> the patch: >>>>>> >>>>>> http://cr.openjdk.java.net/~andrew/ecj/02/webrev.02/ >>>>>> >>>>>> >>>>>> >>>>>> -- Jon >>>>>> >>>>>> [1] >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/compiler-dev/2009-July/001286.html >>>>>> >>>>>> >>>>>> On Aug 18, 2009, at 5:24 AM, Andrew John Hughes wrote: >>>>>> >>>>>> >>>>>> >>>>>> Currently the javac calls for building the bootstrap tools (not the >>>>>> classes for the final JDK, which correctly now use source and target >>>>>> 7) don't set an explicit source and target version. >>>>>> >>>>>> The webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~andrew/ecj/02/webrev.01/ >>>>>> >>>>>> sets these to 6 explicitly, as happens in the Ant builds performed by >>>>>> langtools/jaxp/jaxws. ?This is noticeable especially when using ecj as >>>>>> the bootstrap javac as it defaults to a version < 1.5, and the build >>>>>> fails. >>>>>> >>>>>> Ok to push? >>>>>> >>>>>> Thanks, >>>>>> -- >>>>>> Andrew :-) >>>>>> >>>>>> Free Java Software Engineer >>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>> >>>>>> Support Free Java! >>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>> http://www.gnu.org/software/classpath >>>>>> http://openjdk.java.net >>>>>> >>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Andrew :-) >>>>>> >>>>>> Free Java Software Engineer >>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>> >>>>>> Support Free Java! >>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>> http://www.gnu.org/software/classpath >>>>>> http://openjdk.java.net >>>>>> >>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>>>> >>>>>> >>>>>> >>>>>> Is this version now ok? ?If so, I'll push it to the build gate using >>>>>> the bug ID Kelly allocated for the same fix in JDK. >>>>>> >>>>>> >>>>>> Andrew, >>>>>> >>>>>> I approve your webrev >>>>>> http://cr.openjdk.java.net/~andrew/ecj/02/webrev.02/ >>>>> >>>>> Thanks. ?Pushed this last night: >>>>> http://hg.openjdk.java.net/jdk7/build/corba/rev/8001ba2bf10d >>>>> >>>>>> My earlier confusion was caused by the fact that the corba Makefile is >>>>>> not >>>>>> consistent with the jdk Makefile with respect to the use of >>>>>> SOURCE_LANGUAGE_VERSION. >>>>>> It would be good to (separately) fix that inconsistency, but that does >>>>>> not >>>>>> affect the validity of what you propose here. >>>>>> >>>>> >>>>> Yes, I see what you mean now. ?Here's another webrev: >>>>> >>>>> http://cr.openjdk.java.net/~andrew/consistency/01/webrev.01/ >>>>> >>>>> which should make the two fairly consistent. ?It brings in a lot of >>>>> changes to the version in JDK that seem to have been missed from >>>>> CORBA, namely: >>>>> >>>>> ?* Turning off option outputs on fastdebug builds >>>>> ?* Supporting USE_HOTSPOT_INTERPRETER_MODE >>>>> ?* Supporting JAVAC_MAX_WARNINGS and JAVAC_WARNINGS_FATAL >>>>> ?* The SOURCE_LANGUAGE_VERSION sync above >>>>> ?* Include JAR_JFLAGS in BOOT_JAR_JFLAGS >>>>> >>>>> The following differences remain, which didn't seem appropriate to >>>>> include: >>>>> >>>>> -JAVACFLAGS ?+= -classpath $(BOOTDIR)/lib/tools.jar >>>>> +JAVACFLAGS ?+= "-Xbootclasspath:$(CLASSBINDIR)" >>>>> ?JAVACFLAGS ?+= $(OTHER_JAVACFLAGS) >>>>> >>>>> ?# Needed for javah >>>>> -JAVAHFLAGS += -classpath $(CLASSBINDIR) >>>>> +JAVAHFLAGS += -bootclasspath $(CLASSBINDIR) >>>>> >>>>> I wasn't sure of the pros/cons of these changes but can easy add them >>>>> if needed. >>>>> >>>>>> -- Jon >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Andrew :-) >>>>> >>>>> Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> Support Free Java! >>>>> Contribute to GNU Classpath and the OpenJDK >>>>> http://www.gnu.org/software/classpath >>>>> http://openjdk.java.net >>>>> >>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>>> >>>> >>>> Does this change look ok? Can I push it? >>>> >>>> Thanks, >>>> -- >>>> Andrew :-) >>>> >>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> Support Free Java! >>>> Contribute to GNU Classpath and the OpenJDK >>>> http://www.gnu.org/software/classpath >>>> http://openjdk.java.net >>>> >>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>> >>> Andrew, >>> >>> The changes regarding flags for javac look OK. ?I can't speak to the >>> Hotspot options. >>> >>> -- Jon >>> >>> >>> >>> >>> -- >>> Andrew :-) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>> >> >> >> Ping? >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Thomas.Rodriguez at Sun.COM Tue Sep 1 14:55:27 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 01 Sep 2009 14:55:27 -0700 Subject: PING 1: [PATCH FOR REVIEW]: Sync HOTSPOT_INTERPRETER_MODE usage between CORBA and JDK In-Reply-To: <17c6771e0909011433s233bfd73t6115a669b97cc082@mail.gmail.com> References: <17c6771e0909010245o60b6bb82h516b4c34198694d@mail.gmail.com> <89710453-0F87-458D-8498-A27183F77A0C@sun.com> <17c6771e0909011433s233bfd73t6115a669b97cc082@mail.gmail.com> Message-ID: USE_HOTSPOT_INTERPRETER_MODE appears to be a JDKism so I don't know why our opinion on it should matter. For whatever it's worth, -Xint is a valid hotspot option so I don't see any issue with setting it in a makefile. tom On Sep 1, 2009, at 2:33 PM, Andrew John Hughes wrote: > 2009/9/1 Tom Rodriguez : >> Why are you asking for feedback on a corba build change on hotspot- >> dev? >> Shouldn't this be in build-dev or the corba alias? >> > > As I explained in my original email and as demonstrated by the > forwarded messages in the same mail (both below), the majority of > changes in http://cr.openjdk.java.net/~andrew/consistency/01/webrev.01/ > have already been approved. It was suggested that I ask the HotSpot > team about the addition of USE_HOTSPOT_INTERPRETER_MODE to this > Makefile (the same build machinery is already in the JDK makefile), as > Jonathan didn't feel it his place to comment on these. If this > addition looks ok, then I can commit the change. Specifically, the > chunk is: > > +ifdef USE_HOTSPOT_INTERPRETER_MODE > + JAVA_JVM_FLAGS += -Xint > +endif > >> tom >> >> On Sep 1, 2009, at 2:45 AM, Andrew John Hughes wrote: >> >>> 2009/8/27 Andrew John Hughes : >>>> >>>> The patch http://cr.openjdk.java.net/~andrew/ecj/02/webrev.02/ >>>> syncs >>>> the CORBA Defs-java.gmk to match the JDK version. The javac >>>> changes >>>> have already been approved by Jonathon (see below). Does the >>>> addition >>>> to support USE_HOTSPOT_INTERPRETER_MODE look ok? If so, I'll >>>> push the >>>> patch. >>>> >>>> Thanks. >>>> >>>> ---------- Forwarded message ---------- >>>> From: Jonathan Gibbons >>>> Date: 2009/8/27 >>>> Subject: Re: [PATCH FOR REVIEW]: Make source/target options >>>> explicit >>>> for CORBA bootstrap tools >>>> To: Andrew John Hughes >>>> Cc: build-dev at openjdk.java.net >>>> >>>> >>>> >>>> On Aug 27, 2009, at 3:53 AM, Andrew John Hughes wrote: >>>> >>>>> 2009/8/20 Andrew John Hughes : >>>>>> >>>>>> 2009/8/20 Jonathan Gibbons : >>>>>>> >>>>>>> Andrew John Hughes wrote: >>>>>>> >>>>>>> 2009/8/18 Andrew John Hughes : >>>>>>> >>>>>>> >>>>>>> 2009/8/18 Jonathan Gibbons : >>>>>>> >>>>>>> >>>>>>> Andrew, >>>>>>> >>>>>>> If this is a patch for jdk7, it does not appear to be a patch >>>>>>> to a >>>>>>> recent >>>>>>> copy >>>>>>> of 7. >>>>>>> >>>>>>> >>>>>>> It's against b69 which is the latest release (from Friday). The >>>>>>> patches are against the IcedTea forest so builds can be tested >>>>>>> with >>>>>>> IcedTea as well. >>>>>>> >>>>>>> Specifically, you do not seem to have the recent changeset to >>>>>>> set >>>>>>> >>>>>>> >>>>>>> the source/target used to compile JDK to 7. [1] >>>>>>> >>>>>>> >>>>>>> >>>>>>> Er... yes I do: >>>>>>> >>>>>>> # Add the source level >>>>>>> LANGUAGE_VERSION = -source 7 >>>>>>> JAVACFLAGS += $(LANGUAGE_VERSION) >>>>>>> >>>>>>> # Add the class version we want >>>>>>> TARGET_CLASS_VERSION = 7 >>>>>>> CLASS_VERSION = -target $(TARGET_CLASS_VERSION) >>>>>>> JAVACFLAGS += $(CLASS_VERSION) >>>>>>> JAVACFLAGS += -encoding ascii >>>>>>> JAVACFLAGS += -classpath $(BOOTDIR)/lib/tools.jar >>>>>>> JAVACFLAGS += $(OTHER_JAVACFLAGS) >>>>>>> >>>>>>> but these only cover the rt classes and not the bootstrap >>>>>>> classes. >>>>>>> >>>>>>> >>>>>>> >>>>>>> While your patch does not directly conflict with any edits in >>>>>>> that >>>>>>> patch, >>>>>>> and >>>>>>> while the effect of your patch looks OK, in that patch I was >>>>>>> extending >>>>>>> the >>>>>>> precedent of TARGET_CLASS_VERSION to have an explicit macro for >>>>>>> (just) the version number, so that it is easy to change the >>>>>>> value of >>>>>>> (just) >>>>>>> the version number from the command line. >>>>>>> >>>>>>> With that in mind, I would suggest something like the >>>>>>> following for >>>>>>> your >>>>>>> patch: >>>>>>> >>>>>>> BOOT_SOURCE_LANGUAGE_VERSION = 6 >>>>>>> BOOT_TARGET_CLASS_VERSION = 6 >>>>>>> BOOT_JAVACFLAGS += -encoding ascii -source >>>>>>> $(BOOT_SOURCE_LANGUAGE_VERSION) >>>>>>> -target $(BOOT_TARGET_CLASS_VERSION) >>>>>>> >>>>>>> >>>>>>> >>>>>>> I didn't copy this for the 6 changes because I didn't >>>>>>> immediately see >>>>>>> the point of using variables just for this single use. I >>>>>>> forgot that >>>>>>> it is possible to override these from the command line, so >>>>>>> I've update >>>>>>> the patch: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~andrew/ecj/02/webrev.02/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- Jon >>>>>>> >>>>>>> [1] >>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/compiler-dev/2009-July/001286.html >>>>>>> >>>>>>> >>>>>>> On Aug 18, 2009, at 5:24 AM, Andrew John Hughes wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Currently the javac calls for building the bootstrap tools >>>>>>> (not the >>>>>>> classes for the final JDK, which correctly now use source and >>>>>>> target >>>>>>> 7) don't set an explicit source and target version. >>>>>>> >>>>>>> The webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~andrew/ecj/02/webrev.01/ >>>>>>> >>>>>>> sets these to 6 explicitly, as happens in the Ant builds >>>>>>> performed by >>>>>>> langtools/jaxp/jaxws. This is noticeable especially when >>>>>>> using ecj as >>>>>>> the bootstrap javac as it defaults to a version < 1.5, and the >>>>>>> build >>>>>>> fails. >>>>>>> >>>>>>> Ok to push? >>>>>>> >>>>>>> Thanks, >>>>>>> -- >>>>>>> Andrew :-) >>>>>>> >>>>>>> Free Java Software Engineer >>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>> >>>>>>> Support Free Java! >>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>> http://www.gnu.org/software/classpath >>>>>>> http://openjdk.java.net >>>>>>> >>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Andrew :-) >>>>>>> >>>>>>> Free Java Software Engineer >>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>> >>>>>>> Support Free Java! >>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>> http://www.gnu.org/software/classpath >>>>>>> http://openjdk.java.net >>>>>>> >>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Is this version now ok? If so, I'll push it to the build gate >>>>>>> using >>>>>>> the bug ID Kelly allocated for the same fix in JDK. >>>>>>> >>>>>>> >>>>>>> Andrew, >>>>>>> >>>>>>> I approve your webrev >>>>>>> http://cr.openjdk.java.net/~andrew/ecj/02/webrev.02/ >>>>>> >>>>>> Thanks. Pushed this last night: >>>>>> http://hg.openjdk.java.net/jdk7/build/corba/rev/8001ba2bf10d >>>>>> >>>>>>> My earlier confusion was caused by the fact that the corba >>>>>>> Makefile is >>>>>>> not >>>>>>> consistent with the jdk Makefile with respect to the use of >>>>>>> SOURCE_LANGUAGE_VERSION. >>>>>>> It would be good to (separately) fix that inconsistency, but >>>>>>> that does >>>>>>> not >>>>>>> affect the validity of what you propose here. >>>>>>> >>>>>> >>>>>> Yes, I see what you mean now. Here's another webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~andrew/consistency/01/webrev.01/ >>>>>> >>>>>> which should make the two fairly consistent. It brings in a >>>>>> lot of >>>>>> changes to the version in JDK that seem to have been missed from >>>>>> CORBA, namely: >>>>>> >>>>>> * Turning off option outputs on fastdebug builds >>>>>> * Supporting USE_HOTSPOT_INTERPRETER_MODE >>>>>> * Supporting JAVAC_MAX_WARNINGS and JAVAC_WARNINGS_FATAL >>>>>> * The SOURCE_LANGUAGE_VERSION sync above >>>>>> * Include JAR_JFLAGS in BOOT_JAR_JFLAGS >>>>>> >>>>>> The following differences remain, which didn't seem appropriate >>>>>> to >>>>>> include: >>>>>> >>>>>> -JAVACFLAGS += -classpath $(BOOTDIR)/lib/tools.jar >>>>>> +JAVACFLAGS += "-Xbootclasspath:$(CLASSBINDIR)" >>>>>> JAVACFLAGS += $(OTHER_JAVACFLAGS) >>>>>> >>>>>> # Needed for javah >>>>>> -JAVAHFLAGS += -classpath $(CLASSBINDIR) >>>>>> +JAVAHFLAGS += -bootclasspath $(CLASSBINDIR) >>>>>> >>>>>> I wasn't sure of the pros/cons of these changes but can easy >>>>>> add them >>>>>> if needed. >>>>>> >>>>>>> -- Jon >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Andrew :-) >>>>>> >>>>>> Free Java Software Engineer >>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>> >>>>>> Support Free Java! >>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>> http://www.gnu.org/software/classpath >>>>>> http://openjdk.java.net >>>>>> >>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>> >>>>> >>>>> Does this change look ok? Can I push it? >>>>> >>>>> Thanks, >>>>> -- >>>>> Andrew :-) >>>>> >>>>> Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> Support Free Java! >>>>> Contribute to GNU Classpath and the OpenJDK >>>>> http://www.gnu.org/software/classpath >>>>> http://openjdk.java.net >>>>> >>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>> >>>> Andrew, >>>> >>>> The changes regarding flags for javac look OK. I can't speak to >>>> the >>>> Hotspot options. >>>> >>>> -- Jon >>>> >>>> >>>> >>>> >>>> -- >>>> Andrew :-) >>>> >>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> Support Free Java! >>>> Contribute to GNU Classpath and the OpenJDK >>>> http://www.gnu.org/software/classpath >>>> http://openjdk.java.net >>>> >>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>> >>> >>> >>> Ping? >>> -- >>> Andrew :-) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> >> > > > > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From thomas.rodriguez at sun.com Tue Sep 1 15:49:41 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Tue, 01 Sep 2009 22:49:41 +0000 Subject: hg: hsx/hsx16/baseline: 6862863: C2 compiler fails in elide_copy() Message-ID: <20090901224946.15F5C129CA@hg.openjdk.java.net> Changeset: 0cb45c617c84 Author: never Date: 2009-08-14 15:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/0cb45c617c84 6862863: C2 compiler fails in elide_copy() Reviewed-by: kvn ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/postaloc.cpp From thomas.rodriguez at sun.com Tue Sep 1 18:16:05 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Wed, 02 Sep 2009 01:16:05 +0000 Subject: hg: hsx/hsx16/baseline: 2 new changesets Message-ID: <20090902011611.92E09129EA@hg.openjdk.java.net> Changeset: 10ea1ed1400c Author: never Date: 2009-08-17 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/10ea1ed1400c 6795465: Crash in assembler_sparc.cpp with client compiler on solaris-sparc Reviewed-by: twisti, cfang ! src/cpu/sparc/vm/c1_Defs_sparc.hpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/share/vm/includeDB_compiler1 + test/compiler/6795465/Test6795465.java Changeset: fdfb4ce4a1dd Author: never Date: 2009-08-24 22:26 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/fdfb4ce4a1dd 6875329: fix for 6795465 broke exception handler cloning Reviewed-by: kvn ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp From mark at klomp.org Wed Sep 2 04:29:24 2009 From: mark at klomp.org (Mark Wielaard) Date: Wed, 02 Sep 2009 13:29:24 +0200 Subject: [patch] Adding stack markings to the x86 assembly for not using executable stack In-Reply-To: References: <4A96663B.1040109@ubuntu.com> <17c6771e0908270404t3554158cka2afe14cd636f572@mail.gmail.com> <20090827162542.GJ10947@outflux.net> Message-ID: <1251890964.4946.43.camel@springer.wildebeest.org> On Tue, 2009-09-01 at 13:29 -0700, Tom Rodriguez wrote: > it wouldn't be a bad idea to request non- > executable stacks though this brings up a question about how all this > interacts with shared libraries. If you have an executable that > disables execute and it dlopens a library that doesn't, what happens? > Presumably the executables and libraries have to be in agreement for > this to really work, right? If anything (executable, shared library) needs executable stack ld.so will mark the stack as executable. When you dlopen a shared library that needs executable stack and the stack wasn't marked as executable yet then the stack will be made executable. Except of course when selinux is set to enforce disallowing marking the stack executable (which is a good thing to have, it will quickly catch mistakes like the above). Cheers, Mark From antonios.printezis at sun.com Wed Sep 2 09:31:36 2009 From: antonios.printezis at sun.com (antonios.printezis at sun.com) Date: Wed, 02 Sep 2009 16:31:36 +0000 Subject: hg: hsx/hsx16/baseline: 3 new changesets Message-ID: <20090902163143.834D612A5B@hg.openjdk.java.net> Changeset: a36a6fcb30ab Author: tonyp Date: 2009-08-19 12:53 -0400 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/a36a6fcb30ab 6871111: G1: remove the concurrent overhead tracker Summary: Removing the concurrent overhead tracker from G1, along with the GC overhead reporter and the G1AccountConcurrentOverhead (both of which rely on the the concurrent overhead tracker). Reviewed-by: iveresov, johnc ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/includeDB_gc_shared - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp Changeset: fa8cf6b29408 Author: apetrusenko Date: 2009-08-31 05:27 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/fa8cf6b29408 6841313: G1: dirty cards of survivor regions in parallel Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp Changeset: 13520bae93a6 Author: tonyp Date: 2009-07-30 16:22 -0400 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/13520bae93a6 6819085: G1: use larger and/or user settable region size Summary: Instead of the region size being hard-coded, allow the user to set it. Reviewed-by: jmasa, johnc, apetrusenko ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 From nagy.mostafa at gmail.com Thu Sep 3 11:29:07 2009 From: nagy.mostafa at gmail.com (Nagy Mostafa) Date: Thu, 3 Sep 2009 14:29:07 -0400 Subject: Rewriting bytecode Message-ID: Hi Everyone, I am trying to re-write every method's bytecode right before it executes to expand the opcode field to 4 bytes instead of 1. What is the best way to do that ? From looking at the code, I am confused about the methodOop layout and not sure how to do the resizing. Any code or documentation pointers will be appreciated. thanks, - nagy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090903/2ebf1142/attachment.html From Keith.McGuigan at Sun.COM Thu Sep 3 11:53:47 2009 From: Keith.McGuigan at Sun.COM (Keith McGuigan) Date: Thu, 03 Sep 2009 14:53:47 -0400 Subject: Rewriting bytecode In-Reply-To: References: Message-ID: <4AA010BB.2040106@sun.com> Nagy Mostafa wrote: > Hi Everyone, > I am trying to re-write every method's bytecode right before it executes > to expand the opcode field to 4 bytes instead of 1. What is the best way > to do that ? From looking at the code, I am confused about the methodOop > layout and not sure how to do the resizing. Any code or documentation > pointers will be appreciated. Have you considered java.lang.Instrument to do this, instead of doing it in the VM? If you must do it from with the VM, perhaps start with reading src/share/vm/prims/jvmtiRedefineClasses.hpp and go from there. Changing the bytecode stream is tricky business, especially changing the length of it as you propose. You'll have to update all jump updates and catch clause bounds (and line number tables, etc, if you're into the whole debugging thing); and they'll of course be corner cases where the expanded code size (or jump offset) will overflow the storage that it's currently in and you'll have to rewrite some of the instructions to compensate. It's all doable, I'm sure... but tricky. What are you trying to accomplish? -- - Keith From john.coomes at sun.com Thu Sep 3 12:44:08 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Thu, 03 Sep 2009 19:44:08 +0000 Subject: hg: hsx/hsx16/baseline: 2 new changesets Message-ID: <20090903194412.9092712AE6@hg.openjdk.java.net> Changeset: 5a53320cd23f Author: jcoomes Date: 2009-08-11 15:37 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/5a53320cd23f 6861660: OopMapBlock count/size confusion Reviewed-by: tonyp, iveresov ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp Changeset: e13afc88afa5 Author: jcoomes Date: 2009-08-13 16:22 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/e13afc88afa5 6845368: large objects cause a crash or unexpected exception Reviewed-by: jmasa, iveresov ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp + test/gc/6845368/bigobj.java From nagy.mostafa at gmail.com Thu Sep 3 13:24:28 2009 From: nagy.mostafa at gmail.com (Nagy Mostafa) Date: Thu, 3 Sep 2009 16:24:28 -0400 Subject: Rewriting bytecode In-Reply-To: <4AA010BB.2040106@sun.com> References: <4AA010BB.2040106@sun.com> Message-ID: On Thu, Sep 3, 2009 at 2:53 PM, Keith McGuigan wrote: > Nagy Mostafa wrote: > >> Hi Everyone, I am trying to re-write every method's bytecode right before >> it executes to expand the opcode field to 4 bytes instead of 1. What is the >> best way to do that ? From looking at the code, I am confused about the >> methodOop layout and not sure how to do the resizing. Any code or >> documentation pointers will be appreciated. >> > > Have you considered java.lang.Instrument to do this, instead of doing it in > the VM? > > If you must do it from with the VM, perhaps start with reading > src/share/vm/prims/jvmtiRedefineClasses.hpp and go from there. > > Changing the bytecode stream is tricky business, especially changing the > length of it as you propose. You'll have to update all jump updates and > catch clause bounds (and line number tables, etc, if you're into the whole > debugging thing); and they'll of course be corner cases where the expanded > code size (or jump offset) will overflow the storage that it's currently in > and you'll have to rewrite some of the instructions to compensate. It's all > doable, I'm sure... but tricky. > > What are you trying to accomplish? > > -- > - Keith > Thank you, Keith. I am trying to implement direct-threaded dispatching in Zero interpreter. Currently Zero support either switch-case or indirect threaded. I need to expand every opcode field to be able to accommodate its handler address. So you see, I have to modify the interpreter/vm to dispatch differently, which is easy, I assume. The tricky/hard part like you said is modifying the bytecode. I saw some code in "relocator.cpp" for bytecode re-writing and was wondering if that should do the trick. I looked at "Relocator::insert_space_at()" which I think expands the size of an instruction and adjusts the method layout accordingly. I suppose I can use that and expand the first instruction enough to have enough space to rewrite my code. I still need of course to fix the exception table manually. Does that sound like a good idea ? Do I still need to adjust the linenumber table if i am not doing any debugging ? thanks, - nagy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090903/35157c87/attachment.html From Keith.McGuigan at Sun.COM Thu Sep 3 14:33:28 2009 From: Keith.McGuigan at Sun.COM (Keith McGuigan) Date: Thu, 03 Sep 2009 17:33:28 -0400 Subject: Rewriting bytecode In-Reply-To: References: <4AA010BB.2040106@sun.com> Message-ID: <4AA03628.9070604@sun.com> Nagy Mostafa wrote: > I saw some code in "relocator.cpp" for bytecode re-writing and was > wondering if that should do the trick. I looked at > "Relocator::insert_space_at()" which I think expands the size of an > instruction and adjusts the method layout accordingly. I suppose I can > use that and expand the first instruction enough to have enough space to > rewrite my code. I still need of course to fix the exception table > manually. Does that sound like a good idea ? Do I still need to adjust > the linenumber table if i am not doing any debugging ? Yeah it's worth a shot, I'd think. I wouldn't worry about the linenumber table except that the debugger uses it. -- - Keith From john.coomes at sun.com Thu Sep 3 20:40:57 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 04 Sep 2009 03:40:57 +0000 Subject: hg: jdk7/hotspot: 3 new changesets Message-ID: <20090904034057.8D8B012B4F@hg.openjdk.java.net> Changeset: d8b49b53d8cf Author: wetmore Date: 2009-08-14 17:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/d8b49b53d8cf 6872177: JCE framework and provider builds broken following -target 7 changes Reviewed-by: ohair ! make/Defs-internal.gmk Changeset: 4c36e9853dda Author: tbell Date: 2009-08-24 22:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/4c36e9853dda Merge Changeset: 378f57273f09 Author: xdono Date: 2009-09-03 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/378f57273f09 Added tag jdk7-b71 for changeset 4c36e9853dda ! .hgtags From john.coomes at sun.com Thu Sep 3 20:47:21 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 04 Sep 2009 03:47:21 +0000 Subject: hg: jdk7/hotspot/corba: 4 new changesets Message-ID: <20090904034726.2100A12B54@hg.openjdk.java.net> Changeset: 8001ba2bf10d Author: andrew Date: 2009-08-20 01:28 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/8001ba2bf10d 6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk javac Summary: The bootstrap javac currently uses the default source and targets of the boot javac Reviewed-by: jjg, ohair ! make/common/shared/Defs-java.gmk Changeset: 04414f276160 Author: xdono Date: 2009-08-24 17:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/04414f276160 Merge Changeset: 3f1ef7f899ea Author: andrew Date: 2009-09-01 23:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/3f1ef7f899ea 6878106: Synchronize CORBA and JDK makefiles where possible Summary: Add recent changes to the JDK makefile to the CORBA makefile Reviewed-by: jjg, never ! make/common/shared/Defs-java.gmk Changeset: c793a3120926 Author: xdono Date: 2009-09-03 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/c793a3120926 Added tag jdk7-b71 for changeset 3f1ef7f899ea ! .hgtags From john.coomes at sun.com Thu Sep 3 20:58:36 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 04 Sep 2009 03:58:36 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b71 for changeset ff94d8ce0dad Message-ID: <20090904035839.B7C0A12B59@hg.openjdk.java.net> Changeset: 37c805b6156f Author: xdono Date: 2009-09-03 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/37c805b6156f Added tag jdk7-b71 for changeset ff94d8ce0dad ! .hgtags From john.coomes at sun.com Thu Sep 3 21:06:13 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 04 Sep 2009 04:06:13 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b71 for changeset 03314cf56a72 Message-ID: <20090904040616.9B92C12B5E@hg.openjdk.java.net> Changeset: 4c990aa99bc0 Author: xdono Date: 2009-09-03 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/4c990aa99bc0 Added tag jdk7-b71 for changeset 03314cf56a72 ! .hgtags From john.coomes at sun.com Thu Sep 3 21:14:11 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 04 Sep 2009 04:14:11 +0000 Subject: hg: jdk7/hotspot/jdk: 27 new changesets Message-ID: <20090904042030.4594C12B63@hg.openjdk.java.net> Changeset: 1ff977b938e5 Author: sherman Date: 2009-08-13 10:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1ff977b938e5 6840246: Lightweight implementation of String.split for simple use case Summary: Added a fastpath for simple use case Reviewed-by: alanb, martin ! src/share/classes/java/lang/String.java ! test/java/lang/String/Split.java Changeset: 8c0c96a3f9f6 Author: wetmore Date: 2009-08-13 12:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8c0c96a3f9f6 6870335: Provider numbers need to be bumped to 1.7 Reviewed-by: mullan ! src/share/classes/com/sun/security/sasl/Provider.java ! src/share/classes/sun/security/jgss/SunProvider.java ! src/share/classes/sun/security/provider/Sun.java ! src/share/classes/sun/security/smartcardio/SunPCSC.java ! src/share/classes/sun/security/ssl/SunJSSE.java Changeset: 6797a2407a50 Author: wetmore Date: 2009-08-13 12:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6797a2407a50 Merge Changeset: 35f32639ee20 Author: sherman Date: 2009-08-13 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/35f32639ee20 6676423: (prefs) Opensource unit/regression tests for java.util.prefs Summary: Moved the existing test cases for prefs to open area Reviewed-by: martin, alanb + test/java/util/prefs/CommentsInXml.java + test/java/util/prefs/ConflictInFlush.java + test/java/util/prefs/ExportNode.java + test/java/util/prefs/ExportSubtree.java + test/java/util/prefs/PrefsSpi.java + test/java/util/prefs/PrefsSpi.sh + test/java/util/prefs/RemoveReadOnlyNode.java + test/java/util/prefs/RemoveUnregedListener.java + test/java/util/prefs/SerializeExceptions.java Changeset: f094eb92a6e0 Author: sherman Date: 2009-08-13 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f094eb92a6e0 Merge Changeset: 7fcdefc99dc4 Author: sherman Date: 2009-08-14 11:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7fcdefc99dc4 6866397: (file) PathMatcher with regex syntax doesn't match as expected (win) Summary: Use unicode_case_insensitive for windows path matcher for now. Reviewed-by: alanb ! src/windows/classes/sun/nio/fs/WindowsFileSystem.java ! test/java/nio/file/PathMatcher/Basic.java Changeset: 77a1c2056565 Author: sherman Date: 2009-08-14 14:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/77a1c2056565 6730652: CharsetEncoder.canEncode(char) returns incorrect values for some charsets Summary: override the canEncode() in ISO2022_CN_CNS Reviewed-by: martin ! src/share/classes/sun/nio/cs/ext/ISO2022.java ! src/share/classes/sun/nio/cs/ext/ISO2022_CN_CNS.java ! test/sun/nio/cs/FindCanEncodeBugs.java Changeset: 8414927b41d8 Author: weijun Date: 2009-08-18 10:20 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8414927b41d8 6829785: TextCallbackHandler does not honor PasswordCallback.isEchoOn() Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/callback/TextCallbackHandler.java ! src/share/classes/sun/security/util/Password.java + test/com/sun/security/auth/callback/TextCallbackHandler/Password.java Changeset: 74029d1cf4e4 Author: tbell Date: 2009-08-18 17:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/74029d1cf4e4 Merge Changeset: 5e8986cabdd8 Author: weijun Date: 2009-08-20 11:24 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5e8986cabdd8 6867665: Problem with keytabs with multiple kvno's (key versions) Reviewed-by: valeriep, ohair ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java + test/sun/security/krb5/ktab/HighestKvno.java Changeset: dfece53c600f Author: alanb Date: 2009-08-20 08:39 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dfece53c600f 6595866: File does work with symbolic links (win,vista) Reviewed-by: sherman ! src/windows/native/java/io/WinNTFileSystem_md.c + test/java/io/File/SymLinks.java Changeset: 70c03e494a68 Author: alanb Date: 2009-08-20 08:42 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/70c03e494a68 6870926: (file) Path.toRealPath performance can be improved (win) Reviewed-by: sherman ! src/windows/classes/sun/nio/fs/WindowsFileAttributes.java ! src/windows/classes/sun/nio/fs/WindowsLinkSupport.java ! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c Changeset: 5cd12b68d09b Author: alanb Date: 2009-08-20 08:48 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5cd12b68d09b 6866804: (file) Path calls checkPermission insteadof checkXXX (sol) Reviewed-by: sherman ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/windows/classes/sun/nio/fs/WindowsFileAttributeViews.java + test/java/nio/file/Path/CheckPermissions.java ! test/java/nio/file/Path/Misc.java Changeset: 3992a43bb0a5 Author: darcy Date: 2009-08-21 11:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3992a43bb0a5 6378701: (enum) Unclear purpose of EnumConstantNotPresentException Reviewed-by: lancea, andrew, alanb ! src/share/classes/java/lang/EnumConstantNotPresentException.java ! src/share/classes/java/lang/TypeNotPresentException.java ! src/share/classes/java/lang/annotation/AnnotationFormatError.java ! src/share/classes/java/lang/annotation/AnnotationTypeMismatchException.java ! src/share/classes/java/lang/annotation/IncompleteAnnotationException.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java Changeset: 99a55f6f1cef Author: alanb Date: 2009-08-22 17:40 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/99a55f6f1cef 6874521: Remove @note tags Reviewed-by: andrew, darcy ! src/share/classes/java/nio/channels/Channels.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/FileLock.java ! src/share/classes/java/nio/channels/package-info.java ! src/share/classes/java/nio/file/FileRef.java ! src/share/classes/java/util/Scanner.java Changeset: cef30252932a Author: alanb Date: 2009-08-23 12:53 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cef30252932a 6842687: New I/O: Update Asynchronous I/O API to jsr203/nio2-b101 Reviewed-by: sherman ! make/java/nio/FILES_java.gmk ! src/share/classes/java/nio/channels/AsynchronousByteChannel.java ! src/share/classes/java/nio/channels/AsynchronousChannel.java ! src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/CompletionHandler.java ! src/share/classes/java/nio/channels/exceptions - src/share/classes/sun/nio/ch/AbstractFuture.java ! src/share/classes/sun/nio/ch/AsynchronousChannelGroupImpl.java ! src/share/classes/sun/nio/ch/AsynchronousFileChannelImpl.java ! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/CompletedFuture.java ! src/share/classes/sun/nio/ch/Invoker.java ! src/share/classes/sun/nio/ch/PendingFuture.java ! src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java ! src/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java ! src/solaris/classes/sun/nio/ch/EPollPort.java ! src/solaris/classes/sun/nio/ch/Port.java ! src/solaris/classes/sun/nio/ch/SolarisEventPort.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! src/windows/classes/sun/nio/ch/Iocp.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! src/windows/native/sun/nio/ch/Iocp.c ! test/java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java ! test/java/nio/channels/AsynchronousChannelGroup/Identity.java ! test/java/nio/channels/AsynchronousChannelGroup/Restart.java ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java ! test/java/nio/channels/AsynchronousDatagramChannel/Basic.java ! test/java/nio/channels/AsynchronousFileChannel/Basic.java ! test/java/nio/channels/AsynchronousFileChannel/CustomThreadPool.java ! test/java/nio/channels/AsynchronousFileChannel/Lock.java ! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java + test/java/nio/channels/AsynchronousSocketChannel/DieBeforeComplete.java ! test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java ! test/java/nio/channels/FileChannel/ReleaseOnCloseDeadlock.java Changeset: fca3e1a178fd Author: alanb Date: 2009-08-23 17:20 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fca3e1a178fd Merge Changeset: dbcc1f13e4fd Author: weijun Date: 2009-08-24 18:37 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dbcc1f13e4fd 6875033: regression: test of 6867665 fail Reviewed-by: xuelei ! test/sun/security/krb5/ktab/HighestKvno.java Changeset: d954cd279188 Author: ohair Date: 2009-08-24 09:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d954cd279188 6853636: Fix warnings in jdwpgen, add jdwpgen NetBeans project Reviewed-by: andrew, alanb, tbell, swamyv ! .hgignore + make/netbeans/jdwpgen/build.xml + make/netbeans/jdwpgen/nbproject/build-impl.xml + make/netbeans/jdwpgen/nbproject/findbugs.settings + make/netbeans/jdwpgen/nbproject/genfiles.properties + make/netbeans/jdwpgen/nbproject/project.properties + make/netbeans/jdwpgen/nbproject/project.xml + make/netbeans/jdwpgen/nbproject/sqe.properties ! make/tools/src/build/tools/jdwpgen/AbstractNamedNode.java ! make/tools/src/build/tools/jdwpgen/AltNode.java ! make/tools/src/build/tools/jdwpgen/ConstantSetNode.java ! make/tools/src/build/tools/jdwpgen/Main.java ! make/tools/src/build/tools/jdwpgen/Node.java ! make/tools/src/build/tools/jdwpgen/Parse.java ! make/tools/src/build/tools/jdwpgen/RepeatNode.java ! make/tools/src/build/tools/jdwpgen/SelectNode.java Changeset: dd997cc0c823 Author: vinnie Date: 2009-08-24 18:37 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dd997cc0c823 6872048: bad private keys are generated for 2 specific ECC curves Reviewed-by: wetmore ! src/share/native/sun/security/ec/ec.c ! test/sun/security/ec/TestEC.java Changeset: b71a03c75515 Author: tbell Date: 2009-08-24 22:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b71a03c75515 Merge - src/share/classes/sun/nio/ch/AbstractFuture.java Changeset: 80368890a2a0 Author: andrew Date: 2009-08-18 19:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/80368890a2a0 6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk javac Summary: The bootstrap javac currently uses the default source and targets of the boot javac Reviewed-by: ohair ! make/common/shared/Defs-java.gmk Changeset: 43465920bf47 Author: xdono Date: 2009-08-18 19:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/43465920bf47 Merge - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java Changeset: b3aac0db5586 Author: tbell Date: 2009-08-21 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b3aac0db5586 6705913: freetype_versioncheck.exe - Unable To Locate Component Summary: Update freetype_versioncheck to deal with newer Visual Studio releases Reviewed-by: ohair ! make/tools/freetypecheck/Makefile ! make/tools/freetypecheck/freetypecheck.c Changeset: e0b26d347302 Author: xdono Date: 2009-08-24 17:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e0b26d347302 Merge Changeset: b3f3240135f0 Author: xdono Date: 2009-09-01 13:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b3f3240135f0 Merge - src/share/classes/sun/nio/ch/AbstractFuture.java Changeset: ce3fde68c495 Author: xdono Date: 2009-09-03 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ce3fde68c495 Added tag jdk7-b71 for changeset b3f3240135f0 ! .hgtags From john.coomes at sun.com Thu Sep 3 21:34:13 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 04 Sep 2009 04:34:13 +0000 Subject: hg: jdk7/hotspot/langtools: 11 new changesets Message-ID: <20090904043433.8B58E12B7C@hg.openjdk.java.net> Changeset: 8a03f3c7d160 Author: jjg Date: 2009-08-12 07:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/8a03f3c7d160 6870706: langtools launcher issues Reviewed-by: mcimadamore ! make/build.xml ! src/share/bin/launcher.sh-template Changeset: 71680973d8ec Author: jjg Date: 2009-08-12 07:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/71680973d8ec 6758471: should be able to set jtreg options in langtools build Reviewed-by: mcimadamore ! make/build.properties ! make/build.xml Changeset: 7dbb79875a63 Author: jjg Date: 2009-08-12 10:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/7dbb79875a63 6558476: com/sun/tools/javac/Main.compile don't release file handles on return Reviewed-by: darcy + src/share/classes/com/sun/tools/javac/file/CloseableURLClassLoader.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/T6558476.java Changeset: b055a5ea0dad Author: tbell Date: 2009-08-18 17:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/b055a5ea0dad Merge Changeset: 2aa3a1cdb094 Author: andrew Date: 2009-08-19 20:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/2aa3a1cdb094 6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk Summary: Set source and target explicitly in pcompile task Reviewed-by: jjg ! make/build.xml Changeset: 2ce3597237f0 Author: darcy Date: 2009-08-19 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/2ce3597237f0 6871291: Please clarify javax.tools.JavaCompiler.getTask() "classes" parameter Reviewed-by: jjg ! src/share/classes/javax/tools/JavaCompiler.java Changeset: 61c1f735df67 Author: jjg Date: 2009-08-21 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/61c1f735df67 6873849: suppress notes generated by javac Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/util/Log.java + test/tools/javac/T6873849.java Changeset: d9febdd5ae21 Author: jjg Date: 2009-08-21 14:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d9febdd5ae21 6873845: refine access to symbol file Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/main/JavacOption.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/T6873845.java Changeset: c863e90091ee Author: jjg Date: 2009-08-24 14:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/c863e90091ee 6869216: testgetallmembers should consistently use correct filemanager Reviewed-by: darcy ! test/tools/javac/processing/model/testgetallmembers/Main.java Changeset: 33c8c38e1757 Author: tbell Date: 2009-08-24 22:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/33c8c38e1757 Merge Changeset: d434aa041b52 Author: xdono Date: 2009-09-03 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d434aa041b52 Added tag jdk7-b71 for changeset 33c8c38e1757 ! .hgtags From erik.trimble at sun.com Thu Sep 3 23:51:32 2009 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Fri, 04 Sep 2009 06:51:32 +0000 Subject: hg: hsx/hsx16/baseline: 6830542: Performance: JVM_DefineClass already verified. Message-ID: <20090904065139.A5A0112BC0@hg.openjdk.java.net> Changeset: e6e784127d4c Author: acorn Date: 2009-09-02 22:17 -0400 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/e6e784127d4c 6830542: Performance: JVM_DefineClass already verified. Reviewed-by: kamg, phh ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp From erik.trimble at sun.com Fri Sep 4 00:09:45 2009 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Fri, 04 Sep 2009 07:09:45 +0000 Subject: hg: hsx/hsx16/baseline: 3 new changesets Message-ID: <20090904070954.4214B12BD4@hg.openjdk.java.net> Changeset: dfb34959c7a2 Author: trims Date: 2009-09-03 16:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/dfb34959c7a2 6879058: Change default JPRT release target for 6Update series VMs Summary: Update the JPRT properties file to default to 6u14 Reviewed-by: ohair ! make/jprt.properties Changeset: ae1ac7aa93a3 Author: trims Date: 2009-09-03 16:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/ae1ac7aa93a3 6879061: Bump the HS16 build number to 09 Summary: Update the HS16 build number to 09 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 5979352804a0 Author: trims Date: 2009-09-03 23:58 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/5979352804a0 Merge - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp From andrey.petrusenko at sun.com Fri Sep 4 09:28:38 2009 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Fri, 04 Sep 2009 16:28:38 +0000 Subject: hg: jdk7/hotspot/hotspot: 9 new changesets Message-ID: <20090904162904.22A7F12C74@hg.openjdk.java.net> Changeset: 05f89f00a864 Author: jmasa Date: 2009-08-24 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/05f89f00a864 6798898: CMS: bugs related to class unloading Summary: Override should_remember_klasses() and remember_klass() as needed. Reviewed-by: ysr, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.inline.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/referenceProcessor.cpp Changeset: e1fdf4fd34dc Author: tonyp Date: 2009-08-19 12:53 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e1fdf4fd34dc 6871111: G1: remove the concurrent overhead tracker Summary: Removing the concurrent overhead tracker from G1, along with the GC overhead reporter and the G1AccountConcurrentOverhead (both of which rely on the the concurrent overhead tracker). Reviewed-by: iveresov, johnc ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/includeDB_gc_shared - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp Changeset: ead53f6b615d Author: tonyp Date: 2009-08-24 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ead53f6b615d Merge - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp Changeset: b37c246bf7ce Author: jcoomes Date: 2009-08-11 15:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b37c246bf7ce 6861660: OopMapBlock count/size confusion Reviewed-by: tonyp, iveresov ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp Changeset: 9eebd3ac74cf Author: jcoomes Date: 2009-08-13 16:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9eebd3ac74cf 6845368: large objects cause a crash or unexpected exception Reviewed-by: jmasa, iveresov ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp + test/gc/6845368/bigobj.java Changeset: 8624da129f0b Author: apetrusenko Date: 2009-08-31 05:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8624da129f0b 6841313: G1: dirty cards of survivor regions in parallel Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp Changeset: 8b46c4d82093 Author: ysr Date: 2009-09-02 00:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8b46c4d82093 4957990: Perm heap bloat in JVM Summary: Treat ProfileData in MDO's as a source of weak, not strong, roots. Fixes the bug for stop-world collection -- the case of concurrent collection will be fixed separately. Reviewed-by: jcoomes, jmasa, kvn, never ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.inline.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/includeDB_core ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/oops/methodDataOop.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp Changeset: 2c79770d1f6e Author: tonyp Date: 2009-07-30 16:22 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2c79770d1f6e 6819085: G1: use larger and/or user settable region size Summary: Instead of the region size being hard-coded, allow the user to set it. Reviewed-by: jmasa, johnc, apetrusenko ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: b1606b3c0a8a Author: apetrusenko Date: 2009-09-04 05:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b1606b3c0a8a Merge ! src/share/vm/code/nmethod.cpp - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp From erik.trimble at sun.com Fri Sep 4 09:30:42 2009 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Fri, 04 Sep 2009 16:30:42 +0000 Subject: hg: hsx/hsx16/master: 21 new changesets Message-ID: <20090904163124.68F7412C79@hg.openjdk.java.net> Changeset: dfb34959c7a2 Author: trims Date: 2009-09-03 16:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/dfb34959c7a2 6879058: Change default JPRT release target for 6Update series VMs Summary: Update the JPRT properties file to default to 6u14 Reviewed-by: ohair ! make/jprt.properties Changeset: ae1ac7aa93a3 Author: trims Date: 2009-09-03 16:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/ae1ac7aa93a3 6879061: Bump the HS16 build number to 09 Summary: Update the HS16 build number to 09 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e502d7524e3a Author: kvn Date: 2009-08-26 10:46 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/e502d7524e3a 6827605: new String intrinsics may prevent EA scalar replacement Summary: don't use SSE42 string indexOf intrinsic if it is called for new object which could be scalar replaced. Reviewed-by: never ! src/share/vm/opto/library_call.cpp Changeset: 9f00229d78ce Author: kvn Date: 2009-08-26 12:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/9f00229d78ce 6875866: Intrinsic for String.indexOf() is broken on x86 with SSE4.2 Summary: Start rescan from the next element after the previous match. Reviewed-by: never ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad + test/compiler/6875866/Test.java Changeset: c41db48fadd5 Author: jmasa Date: 2009-08-26 15:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/c41db48fadd5 6798898: CMS: bugs related to class unloading Summary: Override should_remember_klasses() and remember_klass() as needed. Reviewed-by: ysr, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.inline.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/referenceProcessor.cpp Changeset: 1760a1cbed36 Author: dcubed Date: 2009-08-11 11:57 -0600 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/1760a1cbed36 6862945: 4/3 conversion of jmethodID to methodOop in JVMTI is too expensive Summary: Refactor JNIHandles::checked_resolve_jmethod_id() into fast and paranoid parts. Reviewed-by: never, alanb ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/runtime/jniHandles.hpp Changeset: 3cfb7ee91f59 Author: dcubed Date: 2009-08-28 11:10 -0600 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/3cfb7ee91f59 Merge Changeset: 74453a25211d Author: kvn Date: 2009-08-28 11:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/74453a25211d 6876584: parameters order is incorrect for enc_String_Equals() in x86_32.ad Summary: Fixed parameters order for enc_String_Equals() Reviewed-by: never, twisti ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! test/compiler/6875866/Test.java Changeset: 9601152ccfc1 Author: dcubed Date: 2009-08-28 12:25 -0600 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/9601152ccfc1 6875393: 2/3 JNI itable index cache is broken Summary: Add missing initialization of cache size. Reviewed-by: tbell ! src/share/vm/oops/instanceKlass.cpp Changeset: d2d605b757aa Author: dcubed Date: 2009-08-28 14:30 -0600 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/d2d605b757aa Merge ! src/share/vm/oops/instanceKlass.cpp Changeset: 4ca13e754354 Author: dcubed Date: 2009-08-28 15:41 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/4ca13e754354 Merge Changeset: 0cb45c617c84 Author: never Date: 2009-08-14 15:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/0cb45c617c84 6862863: C2 compiler fails in elide_copy() Reviewed-by: kvn ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/postaloc.cpp Changeset: 10ea1ed1400c Author: never Date: 2009-08-17 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/10ea1ed1400c 6795465: Crash in assembler_sparc.cpp with client compiler on solaris-sparc Reviewed-by: twisti, cfang ! src/cpu/sparc/vm/c1_Defs_sparc.hpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/share/vm/includeDB_compiler1 + test/compiler/6795465/Test6795465.java Changeset: fdfb4ce4a1dd Author: never Date: 2009-08-24 22:26 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/fdfb4ce4a1dd 6875329: fix for 6795465 broke exception handler cloning Reviewed-by: kvn ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: a36a6fcb30ab Author: tonyp Date: 2009-08-19 12:53 -0400 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/a36a6fcb30ab 6871111: G1: remove the concurrent overhead tracker Summary: Removing the concurrent overhead tracker from G1, along with the GC overhead reporter and the G1AccountConcurrentOverhead (both of which rely on the the concurrent overhead tracker). Reviewed-by: iveresov, johnc ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/includeDB_gc_shared - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp Changeset: fa8cf6b29408 Author: apetrusenko Date: 2009-08-31 05:27 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/fa8cf6b29408 6841313: G1: dirty cards of survivor regions in parallel Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp Changeset: 13520bae93a6 Author: tonyp Date: 2009-07-30 16:22 -0400 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/13520bae93a6 6819085: G1: use larger and/or user settable region size Summary: Instead of the region size being hard-coded, allow the user to set it. Reviewed-by: jmasa, johnc, apetrusenko ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: 5a53320cd23f Author: jcoomes Date: 2009-08-11 15:37 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/5a53320cd23f 6861660: OopMapBlock count/size confusion Reviewed-by: tonyp, iveresov ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp Changeset: e13afc88afa5 Author: jcoomes Date: 2009-08-13 16:22 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/e13afc88afa5 6845368: large objects cause a crash or unexpected exception Reviewed-by: jmasa, iveresov ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp + test/gc/6845368/bigobj.java Changeset: e6e784127d4c Author: acorn Date: 2009-09-02 22:17 -0400 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/e6e784127d4c 6830542: Performance: JVM_DefineClass already verified. Reviewed-by: kamg, phh ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 5979352804a0 Author: trims Date: 2009-09-03 23:58 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/5979352804a0 Merge - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp From gnu_andrew at member.fsf.org Fri Sep 4 10:21:26 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 4 Sep 2009 18:21:26 +0100 Subject: PING 3: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti Message-ID: <17c6771e0909041021j10a046f0l5eec2e765bbe32e5@mail.gmail.com> 2009/9/1 Andrew John Hughes : > 2009/8/24 Andrew John Hughes : >> 2009/8/22 Andrew John Hughes : >>> 2009/8/22 David Schlosnagle : >>>> Andrew, >>>> >>>> I'm just a beginner here trying to get a better understanding of the JDK by >>>> scanning code reviews and I have a comment on the changes in >>>> . >>>> >>>> In all the sa.make files (Linux, Solaris & Windows), should the -g flag be >>>> removed from the two modified lines since it's included in the >>>> SA_JAVAC_FLAGS via JAVAC_FLAGS in defs.make? I'd assume that the duplicate >>>> -g won't cause failures, but it seems to force all debug info to always be >>>> included even if one tried to override the compile flags to disable or alter >>>> the debug information included. >>>> >>>> Thanks, >>>> David Schlosnagle >>>> >>> >>> Well spotted! They should have been removed. ?Revised in >>> http://cr.openjdk.java.net/~andrew/ecj/03/webrev.04 >>> >>>> >>>> On Thu, Aug 20, 2009 at 8:22 AM, Andrew John Hughes >>>> wrote: >>>>> >>>>> 2009/8/20 John Coomes : >>>>> > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: >>>>> >> 2009/8/18 John Coomes : >>>>> >> > Daniel D. Daugherty (Daniel.Daugherty at Sun.COM) wrote: >>>>> >> >> Andrew, >>>>> >> >> >>>>> >> >> A couple of comments: >>>>> >> >> >>>>> >> >> - if you specify '-source 6', then '-target 6' is implied >>>>> >> >> ?? so you don't really need both >>>>> >> >> - I would prefer to see a top-level macro that defines the >>>>> >> >> ?? bootstrap tools javac option and then have the various >>>>> >> >> ?? Makefiles use that macro. Something in make/defs.make: >>>>> >> >> >>>>> >> >> ?? ?? ?? BOOTSTRAP_TOOLS.JAVAC.FLAGS="-source 6" >>>>> >> >> >>>>> >> >> ?? or something like that. >>>>> >> > >>>>> >> > +1 on the top-level macro. ??In HotSpot, I would call it JAVAC_FLAGS >>>>> >> > or >>>>> >> > COMPILE_JAVAC_FLAGS, and add it to the COMPILE.JAVAC macro (spelled >>>>> >> > COMPILE_JAVAC on windows) so that every compilation uses it. ??Then >>>>> >> > fewer places need to be touched. >>>>> >> > >>>>> >> > Also, please leave the default value empty. ??On platforms that need >>>>> >> > it, it can be set on the command line or in the environment. >>>>> >> > Specifying a value requires periodic maintenance. ??Yes, the period >>>>> >> > is >>>>> >> > long, but it's a pain when the build breaks because of some stale >>>>> >> > value in a makefile. >>>>> >> > >>>>> >> >>>>> >> Ok, here's the changeset I was working on before I received your mail >>>>> >> and which I've since successfully tested with hotspot-rt: >>>>> >> >>>>> >> http://cr.openjdk.java.net/~andrew/ecj/03/webrev.02/ >>>>> > >>>>> > I submitted your patch to the build queue; it will take several hours, >>>>> > there's one job ahead of it. >>>>> > >>>>> > After looking at it again, the include of make/defs.make in >>>>> > make/windows/makefiles/rules.make will most likely fail to build. ?The >>>>> > latter is a windows nmake file, so the gnu-specific syntax will be >>>>> > rejected and there are other unixisms in there (e.g., shell until). >>>>> > >>>>> >>>>> I had a feeling Windows would be the one to bite... >>>>> >>>>> > Instead, try updating MAKE_ARGS in make/defs.make, I believe those are >>>>> > exported to sub-makes. ?Since it has to be portable, I believe you'll >>>>> > have to use '_' instead of '.' in the macro name. >>>>> > >>>>> >>>>> Ok, in http://cr.openjdk.java.net/~andrew/ecj/03/webrev.03/ I've >>>>> reverted the addtion >>>>> of defs.make in favour of using MAKE_ARGS and renamed the variables >>>>> using underscores (which I prefer anyway). >>>>> >>>>> Where I am confused is how the MAKE_ARGS changes get through to the >>>>> Windows build if it doesn't parse defs.make. >>>>> makefiles/windows/defs.make seems to imply that the top-level one will >>>>> be read. >>>>> >>>>> >> This defines the variables in the top-level defs.make file. ?The >>>>> >> versions are stored separately, in the same way as they are in the >>>>> >> JDK: >>>>> >> >>>>> >> http://hg.openjdk.java.net/jdk7/build/jdk/rev/80368890a2a0 >>>>> >> >>>>> >> SA is still done separately as it's currently 1.4. ?The default for >>>>> >> others is 6. >>>>> >> The rest of the patch ensures this makefile is picked up and its >>>>> >> values used for compilation across all three platforms. >>>>> >> >>>>> >> This is added to the invocations rather than COMPILE.JAVAC. ?As you >>>>> >> imply in your mail, this value varies between platforms and even >>>>> >> within the same platform. ?Just the GNU/Linux port itself defines it >>>>> >> in about four ways. >>>>> > >>>>> > Take a look, it's simply selecting which path to use. ?After the def >>>>> > of COMPILE.JAVAC, a simple >>>>> > >>>>> > ? ? ? ?COMPILE.JAVAC += $(BOOTSTRAP_JAVAC.FLAGS) >>>>> > >>>>> > should do it. ?Windows will have to be different, though. >>>>> > >>>>> >>>>> Yes, the other problem is this forces the same options to SA as well >>>>> which uses COMPILE.JAVAC. ?To keep the current status quo (at least >>>>> for now), these need a different set of flags. >>>>> >>>>> >> I don't agree with leaving the value blank. ?The issue is relevant on >>>>> >> all platforms, as leaving it blank makes the build open to whatever >>>>> >> the default value is of the bootstrap JDK. ?For instance, this just >>>>> >> changed to 7 with OpenJDK, so current builds will produce 1.7 bytecode >>>>> >> while builds using an older OpenJDK7 or OpenJDK6 will use 6. ?From >>>>> >> personal experience, it's much harder to debug a problem when you have >>>>> >> to take into account the boot JDK being used, which may vary, than >>>>> >> when you have an explicit value. >>>>> >> >>>>> >> It seems much clearer to specify it explicitly in one common place for >>>>> >> all platforms, which can also be easily overridden from the command >>>>> >> line if needed. ?This is the same as is now done for JDK, langtools, >>>>> >> jaxp and jaxws and will shortly be the case in corba. >>>>> > >>>>> > The jdk, langtools, etc., repos are much more sensitive to this >>>>> > setting than hotspot, which uses it only for makedeps and jvmti header >>>>> > generation. ?It's non-critical, and I think it's safe to assume that >>>>> > the default class file version produced by a boot jdk can also be run >>>>> > by that same boot jdk. >>>>> > >>>>> > So far, ecj is the only known boot env needing this set explicitly. >>>>> > >>>>> >>>>> That kind of assumption is the thing that tends to come back and bite >>>>> you. ?It's especially true because: >>>>> >>>>> ?* The boot JDK is something determined on a per-user basis, so just >>>>> updating the system JDK may cause a failure that's hard to diagnose. >>>>> ?* Failures in HotSpot javac builds are already hard to diagnose >>>>> because it doesn't print out the javac invocation. ?It took me longer >>>>> to track this down than the equivalents in JDK and CORBA, and I've >>>>> been working with the OpenJDK build for about two years now. >>>>> >>>>> Yes, ecj is the only one that fails. ?But we now have at least two >>>>> JDKs that will produce different results: OpenJDK6 (which defaults to >>>>> 6) and OpenJDK7 (which defaults to 7). ?There are even more if you >>>>> include the proprietary JDKs and JDK 1.5 which I assume can also build >>>>> OpenJDK at a push. >>>>> >>>>> One of the side effects of releasing code to the world is that people >>>>> are going to try and run into all sorts of corner cases. ?Assuming the >>>>> defaults are good works fine when the only people building the code >>>>> are Sun developers, but this is no longer true and something like this >>>>> is just the kind of thing a casual builder of the code will run into >>>>> and wonder why it fails. >>>>> >>>>> I agree this code is less used than the equivalent JDK and CORBA code, >>>>> but surely it's better to be as consistent as possible across the >>>>> codebase? >>>>> >>>>> Finally, switching SA to use the defaults would be a visible change. >>>>> >>>>> > -John >>>>> > >>>>> >> >> Which repo are you targeting for this change? >>>>> >> > >>>>> >> > I'd suggest hotspot-rt. >>>>> >> > >>>>> >> > Note that all hotspot changes have to be built on all platforms >>>>> >> > before >>>>> >> > being pushed; we have an automated system called jprt that does >>>>> >> > builds >>>>> >> > and tests on the various platforms. ??Unfortunately, it isn't >>>>> >> > available >>>>> >> > externally. ??Sync up with the latest hotspot-rt and then contact me >>>>> >> > privately with a patch or your repo location and I'll run it through. >>>>> >> > >>>>> >> >>>>> >> The patch from this webrev is against hotspot-rt so can be tested. >>>>> >> >>>>> >> >> Yes, I see that SA uses '-source 1.4' in each platform makefile. >>>>> >> >> That should be fixed also, but that's another issue... >>>>> >> > >>>>> >> > Sigh. ??Stale values in makefiles ... >>>>> >> > >>>>> >> >>>>> >> Also fixed now by this patch. ?At least 1.4 is in one common makefile >>>>> >> rather than occurring six times over three makefiles... :) >>>>> >> >>>>> >> > -John >>>>> >> > >>>>> >> >> > Andrew John Hughes wrote: >>>>> >> >> > The makeDeps and jvmti bootstrap tools are built without explicit >>>>> >> >> > source and target options. >>>>> >> >> > >>>>> >> >> > This webrev: >>>>> >> >> > >>>>> >> >> > http://cr.openjdk.java.net/~andrew/ecj/03/webrev.01/ >>>>> >> >> > >>>>> >> >> > sets them to 6 explicitly. The change has to be replicated three >>>>> >> >> > times, because for some reason, the javac invocations are in >>>>> >> >> > platform-specific makefiles. ??I've tested the change successfully >>>>> >> >> > on >>>>> >> >> > GNU/Linux, where it allows ecj to be used as javac. ??ecj defaults >>>>> >> >> > to >>>>> >> >> > <1.5 and thus otherwise fails to build. ??I've assumed that the >>>>> >> >> > same >>>>> >> >> > changes are applicable for Solaris and Windows, and that the >>>>> >> >> > source >>>>> >> >> > and target options don't have to be written in Latin or something >>>>> >> >> > to >>>>> >> >> > work on these platforms. >>>>> >> >> > >>>>> >> >> > Is this ok to push? >>>>> >> >> > >>>>> >> >> > Thanks, >>>>> >> >> > >>>>> >> > >>>>> >> > >>>>> >> >>>>> >> >>>>> >> >>>>> >> -- >>>>> >> Andrew :-) >>>>> >> >>>>> >> Free Java Software Engineer >>>>> >> Red Hat, Inc. (http://www.redhat.com) >>>>> >> >>>>> >> Support Free Java! >>>>> >> Contribute to GNU Classpath and the OpenJDK >>>>> >> http://www.gnu.org/software/classpath >>>>> >> http://openjdk.java.net >>>>> >> >>>>> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>> >> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>>> > >>>>> > >>>>> >>>>> >>>>> >>>>> -- >>>>> Andrew :-) >>>>> >>>>> Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> Support Free Java! >>>>> Contribute to GNU Classpath and the OpenJDK >>>>> http://www.gnu.org/software/classpath >>>>> http://openjdk.java.net >>>>> >>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>> >>>> >>> >>> >>> >>> -- >>> Andrew :-) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>> >> >> >> Is this now ok to push? It passed the build. >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >> > > Ping? > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > Hello? Can I push this change or not? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From John.Coomes at sun.com Fri Sep 4 10:55:21 2009 From: John.Coomes at sun.com (John Coomes) Date: Fri, 4 Sep 2009 10:55:21 -0700 Subject: PING 3: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <17c6771e0909041021j10a046f0l5eec2e765bbe32e5@mail.gmail.com> References: <17c6771e0909041021j10a046f0l5eec2e765bbe32e5@mail.gmail.com> Message-ID: <19105.21641.434524.306543@sun.com> Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: > > Hello? > > Can I push this change or not? I've had two high priority things come up. I'll take a look later today. -John From gnu_andrew at member.fsf.org Fri Sep 4 12:03:44 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 4 Sep 2009 20:03:44 +0100 Subject: PING 3: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <19105.21641.434524.306543@sun.com> References: <17c6771e0909041021j10a046f0l5eec2e765bbe32e5@mail.gmail.com> <19105.21641.434524.306543@sun.com> Message-ID: <17c6771e0909041203x7b405e78pbc1586c3d26f5504@mail.gmail.com> 2009/9/4 John Coomes : > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: >> >> Hello? >> >> Can I push this change or not? > > I've had two high priority things come up. ?I'll take a look later > today. > > -John > > Ok, thanks John. It's just a bit worrying when things go all silent :) To recap, the changeset passed the Sun build you ran for me, and I think we resolved all the issues from the comments. So, as far as I'm aware, it should be okay now, fingers crossed. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Fri Sep 4 15:18:39 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 4 Sep 2009 23:18:39 +0100 Subject: [PATCH FOR REVIEW]: Fix warning in src/share/vm/adlc/archDesc.cpp Message-ID: <17c6771e0909041518h20c4c809x27db9f5823896795@mail.gmail.com> If HotSpot is built with gcc 4.4 and CFLAGS contains -O2, it fails with the following warning (due to -Werror): g++ -DLINUX -D_GNU_SOURCE -DAMD64 -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/asm -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/ci -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/classfile -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/code -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/compiler -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_implementation -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_implementation/g1 -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_implementation/parallelScavenge -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_implementation/parNew -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_implementation/shared -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_interface -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/interpreter -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/libadt -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/memory -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/oops -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/opto -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/prims -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/runtime -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/services -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/shark -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/utilities -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/cpu/x86/vm -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/os/linux/vm -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/os_cpu/linux_x86/vm -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc -I../generated -DASSERT -g -O2 -DCOMPILER2 -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -m64 -pipe -g -DCOMPILER2 -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -m64 -pipe -g -Werror -c -o ../generated/adfiles/archDesc.o /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp cc1plus: warnings being treated as errors /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp: In member function 'void ArchDesc::addSunCopyright(char*, int, FILE*)': /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp:1034: error: ignoring return value of 'size_t fwrite(const void*, size_t, size_t, FILE*)', declared with attribute warn_unused_result The webrev: http://cr.openjdk.java.net/~andrew/werror/webrev.01/ fixes this by storing the result (I tried a simple cast to (void*) but gcc wasn't happy with this). Ok to commit? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Paul.Hohensee at Sun.COM Fri Sep 4 15:41:52 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 04 Sep 2009 18:41:52 -0400 Subject: [PATCH FOR REVIEW]: Fix warning in src/share/vm/adlc/archDesc.cpp In-Reply-To: <17c6771e0909041518h20c4c809x27db9f5823896795@mail.gmail.com> References: <17c6771e0909041518h20c4c809x27db9f5823896795@mail.gmail.com> Message-ID: <4AA197B0.10008@sun.com> Try a cast to (void). Paul Andrew John Hughes wrote: > If HotSpot is built with gcc 4.4 and CFLAGS contains -O2, it fails > with the following warning (due to -Werror): > > g++ -DLINUX -D_GNU_SOURCE -DAMD64 > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/asm > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/ci > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/classfile > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/code > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/compiler > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_implementation > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_implementation/g1 > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_implementation/parallelScavenge > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_implementation/parNew > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_implementation/shared > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_interface > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/interpreter > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/libadt > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/memory > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/oops > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/opto > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/prims > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/runtime > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/services > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/shark > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/utilities > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/cpu/x86/vm > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/os/linux/vm > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/os_cpu/linux_x86/vm > -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc > -I../generated -DASSERT -g -O2 -DCOMPILER2 -fno-rtti -fno-exceptions > -D_REENTRANT -fcheck-new -m64 -pipe -g -DCOMPILER2 -fno-rtti > -fno-exceptions -D_REENTRANT -fcheck-new -m64 -pipe -g -Werror -c -o > ../generated/adfiles/archDesc.o > /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp > cc1plus: warnings being treated as errors > /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp: > In member function 'void ArchDesc::addSunCopyright(char*, int, > FILE*)': > /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp:1034: > error: ignoring return value of 'size_t fwrite(const void*, size_t, > size_t, FILE*)', declared with attribute warn_unused_result > > The webrev: > > http://cr.openjdk.java.net/~andrew/werror/webrev.01/ > > fixes this by storing the result (I tried a simple cast to (void*) but > gcc wasn't happy with this). > > Ok to commit? > From gnu_andrew at member.fsf.org Fri Sep 4 16:25:46 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sat, 5 Sep 2009 00:25:46 +0100 Subject: [PATCH FOR REVIEW]: Fix warning in src/share/vm/adlc/archDesc.cpp In-Reply-To: <4AA197B0.10008@sun.com> References: <17c6771e0909041518h20c4c809x27db9f5823896795@mail.gmail.com> <4AA197B0.10008@sun.com> Message-ID: <17c6771e0909041625xe756218l936ae08a84428b3e@mail.gmail.com> 2009/9/4 Paul Hohensee : > Try a cast to (void). > As I said (or meant to, mental typo), this doesn't fix it. GCC still complains. > Paul > > Andrew John Hughes wrote: >> >> If HotSpot is built with gcc 4.4 and CFLAGS contains -O2, it fails >> with the following warning (due to -Werror): >> >> g++ -DLINUX -D_GNU_SOURCE -DAMD64 >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/asm >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/ci >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/classfile >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/code >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/compiler >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_implementation >> >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_implementation/g1 >> >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_implementation/parallelScavenge >> >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep >> >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_implementation/parNew >> >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_implementation/shared >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/gc_interface >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/interpreter >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/libadt >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/memory >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/oops >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/opto >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/prims >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/runtime >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/services >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/shark >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/utilities >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/cpu/x86/vm >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/os/linux/vm >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/os_cpu/linux_x86/vm >> -I/mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc >> -I../generated -DASSERT -g -O2 -DCOMPILER2 ?-fno-rtti -fno-exceptions >> -D_REENTRANT -fcheck-new -m64 -pipe -g -DCOMPILER2 ?-fno-rtti >> -fno-exceptions -D_REENTRANT -fcheck-new -m64 -pipe -g -Werror -c -o >> ../generated/adfiles/archDesc.o >> /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp >> cc1plus: warnings being treated as errors >> /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp: >> In member function 'void ArchDesc::addSunCopyright(char*, int, >> FILE*)': >> >> /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp:1034: >> error: ignoring return value of 'size_t fwrite(const void*, size_t, >> size_t, FILE*)', declared with attribute warn_unused_result >> >> The webrev: >> >> http://cr.openjdk.java.net/~andrew/werror/webrev.01/ >> >> fixes this by storing the result (I tried a simple cast to (void*) but >> gcc wasn't happy with this). >> >> Ok to commit? >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From John.Coomes at sun.com Fri Sep 4 22:40:10 2009 From: John.Coomes at sun.com (John Coomes) Date: Fri, 4 Sep 2009 22:40:10 -0700 Subject: PING 3: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <17c6771e0909041203x7b405e78pbc1586c3d26f5504@mail.gmail.com> References: <17c6771e0909041021j10a046f0l5eec2e765bbe32e5@mail.gmail.com> <19105.21641.434524.306543@sun.com> <17c6771e0909041203x7b405e78pbc1586c3d26f5504@mail.gmail.com> Message-ID: <19105.63930.845263.728467@sun.com> Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: > 2009/9/4 John Coomes : > > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: > >> > >> Hello? > >> > >> Can I push this change or not? > > > > I've had two high priority things come up. ??I'll take a look later > > today. > > > > Ok, thanks John. It's just a bit worrying when things go all silent :) > > To recap, the changeset passed the Sun build you ran for me, and I > think we resolved all the issues from the comments. So, as far as I'm > aware, it should be okay now, fingers crossed. Unfortunately, your changes break when builds are done the way many (most?) long-time HotSpot developers do them, which is cd /make/solaris # or linux or windows gmake fastdebug # on windows it's nmake debug or build.bat ... That's the traditional way to make HotSpot, has been for most of a decade. The new JAVAC_FLAGS aren't passed down; most likely because defs.make isn't read. FWIW, the automated build system (JPRT) starts a build like this: cd /make gmake fastdebug This was added a few years ago. Would be nice to have 'one build to rule them all' but others have to agree before we can give up the old way. Also, in prior email I suggested: > ..., if you update JAVAC_COMPILE to include BOOTSTRAP_JAVAC_FLAGS (or > whatever it is), and the SA makefile also includes -source/-target > options on the command-line, the latter will override the ones in > BOOTSTRAP_JAVAC_FLAGS (the SA command line may need to include both > -source and -target). At least try it, I think it'll be a simpler change. -John From Christian.Thalinger at Sun.COM Sat Sep 5 01:40:12 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sat, 05 Sep 2009 10:40:12 +0200 Subject: [PATCH FOR REVIEW]: Fix warning in src/share/vm/adlc/archDesc.cpp In-Reply-To: <17c6771e0909041625xe756218l936ae08a84428b3e@mail.gmail.com> References: <17c6771e0909041518h20c4c809x27db9f5823896795@mail.gmail.com> <4AA197B0.10008@sun.com> <17c6771e0909041625xe756218l936ae08a84428b3e@mail.gmail.com> Message-ID: <4AA223EC.1010802@Sun.COM> Andrew John Hughes wrote: > 2009/9/4 Paul Hohensee : >> Try a cast to (void). >> > > As I said (or meant to, mental typo), this doesn't fix it. GCC still complains. Yeah, there already were some discussions about this new behavior and I personally don't really like it. When I want to ignore a return value the compiler should honor that and go ahead. Is there a compiler flag to turn that behavior off? -- Christian From Christian.Thalinger at Sun.COM Sat Sep 5 01:59:16 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sat, 05 Sep 2009 10:59:16 +0200 Subject: [PATCH FOR REVIEW]: Fix warning in src/share/vm/adlc/archDesc.cpp In-Reply-To: <4AA223EC.1010802@Sun.COM> References: <17c6771e0909041518h20c4c809x27db9f5823896795@mail.gmail.com> <4AA197B0.10008@sun.com> <17c6771e0909041625xe756218l936ae08a84428b3e@mail.gmail.com> <4AA223EC.1010802@Sun.COM> Message-ID: <4AA22864.6020202@Sun.COM> Christian Thalinger wrote: > Andrew John Hughes wrote: >> 2009/9/4 Paul Hohensee : >>> Try a cast to (void). >>> >> As I said (or meant to, mental typo), this doesn't fix it. GCC still complains. > > Yeah, there already were some discussions about this new behavior and I > personally don't really like it. When I want to ignore a return value > the compiler should honor that and go ahead. Is there a compiler flag > to turn that behavior off? Well, looking more closely it's actually a system header attribute that brings up that warning: /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp:1034: error: ignoring return value of 'size_t fwrite(const void*, size_t, size_t, FILE*)', declared with attribute warn_unused_result And it seems there is no GCC switch to turn that warning off (except -O0). Maybe we should check for the written bytes to be the same as requested: assert(count == size, "copyright info truncated"); -- Christian From David.Holmes at Sun.COM Sat Sep 5 04:36:47 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Sat, 05 Sep 2009 21:36:47 +1000 Subject: [PATCH FOR REVIEW]: Fix warning in src/share/vm/adlc/archDesc.cpp In-Reply-To: <4AA22864.6020202@Sun.COM> References: <17c6771e0909041518h20c4c809x27db9f5823896795@mail.gmail.com> <4AA197B0.10008@sun.com> <17c6771e0909041625xe756218l936ae08a84428b3e@mail.gmail.com> <4AA223EC.1010802@Sun.COM> <4AA22864.6020202@Sun.COM> Message-ID: <4AA24D4F.2010908@sun.com> Christian Thalinger said the following on 09/05/09 18:59: > Well, looking more closely it's actually a system header attribute that > brings up that warning: > > /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp:1034: > error: ignoring return value of 'size_t fwrite(const void*, size_t, > size_t, FILE*)', declared with attribute warn_unused_result > > And it seems there is no GCC switch to turn that warning off (except > -O0). Maybe we should check for the written bytes to be the same as > requested: > > assert(count == size, "copyright info truncated"); I recall this coming up in the past. gcc manual lists: -Wno-unused-result but that might be version specific. David From gnu_andrew at member.fsf.org Sun Sep 6 06:40:14 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sun, 6 Sep 2009 14:40:14 +0100 Subject: [PATCH FOR REVIEW]: Fix warning in src/share/vm/adlc/archDesc.cpp In-Reply-To: <4AA24D4F.2010908@sun.com> References: <17c6771e0909041518h20c4c809x27db9f5823896795@mail.gmail.com> <4AA197B0.10008@sun.com> <17c6771e0909041625xe756218l936ae08a84428b3e@mail.gmail.com> <4AA223EC.1010802@Sun.COM> <4AA22864.6020202@Sun.COM> <4AA24D4F.2010908@sun.com> Message-ID: <17c6771e0909060640w75fa3da3x8bcf0c387b1c151@mail.gmail.com> 2009/9/5 David Holmes - Sun Microsystems : > Christian Thalinger said the following on 09/05/09 18:59: >> >> Well, looking more closely it's actually a system header attribute that >> brings up that warning: >> >> >> /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp:1034: >> error: ignoring return value of 'size_t fwrite(const void*, size_t, >> size_t, FILE*)', declared with attribute warn_unused_result >> >> And it seems there is no GCC switch to turn that warning off (except >> -O0). ?Maybe we should check for the written bytes to be the same as >> requested: >> >> ?assert(count == size, "copyright info truncated"); > > I recall this coming up in the past. gcc manual lists: > > -Wno-unused-result > > but that might be version specific. > > David > It's a very recent addition: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00474.html which means there is a period (which includes GCC 4.4) where the warning is produced but can't be disabled :( BTW, my current approach was influenced by http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/2328d1d3f8cf where the same fix is applied to remove this warning. I have to say I personally prefer twisti's assert fix and can apply this if others are in agreement. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Sun Sep 6 06:42:20 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sun, 6 Sep 2009 14:42:20 +0100 Subject: PING 3: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <19105.63930.845263.728467@sun.com> References: <17c6771e0909041021j10a046f0l5eec2e765bbe32e5@mail.gmail.com> <19105.21641.434524.306543@sun.com> <17c6771e0909041203x7b405e78pbc1586c3d26f5504@mail.gmail.com> <19105.63930.845263.728467@sun.com> Message-ID: <17c6771e0909060642y38631c09xf86f1121d938bb38@mail.gmail.com> 2009/9/5 John Coomes : > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: >> 2009/9/4 John Coomes : >> > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: >> >> >> >> Hello? >> >> >> >> Can I push this change or not? >> > >> > I've had two high priority things come up. ??I'll take a look later >> > today. >> > >> >> Ok, thanks John. ?It's just a bit worrying when things go all silent :) >> >> To recap, the changeset passed the Sun build you ran for me, and I >> think we resolved all the issues from the comments. ?So, as far as I'm >> aware, it should be okay now, fingers crossed. > > Unfortunately, your changes break when builds are done the way many > (most?) long-time HotSpot developers do them, which is > > ? ? ? ?cd /make/solaris ?# or linux or windows > ? ? ? ?gmake fastdebug ? ? ? ? # on windows it's nmake debug or build.bat ... > > That's the traditional way to make HotSpot, has been for most of a > decade. ?The new JAVAC_FLAGS aren't passed down; most likely because > defs.make isn't read. > > FWIW, the automated build system (JPRT) starts a build like this: > > ? ? ? ?cd /make > ? ? ? ?gmake fastdebug > > This was added a few years ago. ?Would be nice to have 'one build to > rule them all' but others have to agree before we can give up the old > way. > Ok so this sounds like we need to go back to something similar to what I started with, and patch each individual platform Makefile. Is that correct? > Also, in prior email I suggested: > >> ..., if you update JAVAC_COMPILE to include BOOTSTRAP_JAVAC_FLAGS (or >> whatever it is), and the SA makefile also includes -source/-target >> options on the command-line, the latter will override the ones in >> BOOTSTRAP_JAVAC_FLAGS (the SA command line may need to include both >> -source and -target). ?At least try it, I think it'll be a simpler change. > Ok, I must have missed this. It sounds a good idea and in the long term I presume we want to get rid of the SA overrides anyway. > -John > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Mon Sep 7 07:17:57 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 7 Sep 2009 15:17:57 +0100 Subject: PING 3: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <17c6771e0909060642y38631c09xf86f1121d938bb38@mail.gmail.com> References: <17c6771e0909041021j10a046f0l5eec2e765bbe32e5@mail.gmail.com> <19105.21641.434524.306543@sun.com> <17c6771e0909041203x7b405e78pbc1586c3d26f5504@mail.gmail.com> <19105.63930.845263.728467@sun.com> <17c6771e0909060642y38631c09xf86f1121d938bb38@mail.gmail.com> Message-ID: <17c6771e0909070717k60d2be5cpce809698dc5aa0cb@mail.gmail.com> 2009/9/6 Andrew John Hughes : > 2009/9/5 John Coomes : >> Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: >>> 2009/9/4 John Coomes : >>> > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: >>> >> >>> >> Hello? >>> >> >>> >> Can I push this change or not? >>> > >>> > I've had two high priority things come up. ??I'll take a look later >>> > today. >>> > >>> >>> Ok, thanks John. ?It's just a bit worrying when things go all silent :) >>> >>> To recap, the changeset passed the Sun build you ran for me, and I >>> think we resolved all the issues from the comments. ?So, as far as I'm >>> aware, it should be okay now, fingers crossed. >> >> Unfortunately, your changes break when builds are done the way many >> (most?) long-time HotSpot developers do them, which is >> >> ? ? ? ?cd /make/solaris ?# or linux or windows >> ? ? ? ?gmake fastdebug ? ? ? ? # on windows it's nmake debug or build.bat ... >> >> That's the traditional way to make HotSpot, has been for most of a >> decade. ?The new JAVAC_FLAGS aren't passed down; most likely because >> defs.make isn't read. >> >> FWIW, the automated build system (JPRT) starts a build like this: >> >> ? ? ? ?cd /make >> ? ? ? ?gmake fastdebug >> >> This was added a few years ago. ?Would be nice to have 'one build to >> rule them all' but others have to agree before we can give up the old >> way. >> > > Ok so this sounds like we need to go back to something similar to what > I started with, and patch each individual platform Makefile. ?Is that > correct? > Here's a revised webrev: http://cr.openjdk.java.net/~andrew/ecj/03/webrev.05/hotspot.patch using rules.make for each platform instead of the top-level defs.make. It also includes the replacement of separate SA flags with just adding the same flags to SA and then following that with -source/target 1.4. Is this ok? >> Also, in prior email I suggested: >> >>> ..., if you update JAVAC_COMPILE to include BOOTSTRAP_JAVAC_FLAGS (or >>> whatever it is), and the SA makefile also includes -source/-target >>> options on the command-line, the latter will override the ones in >>> BOOTSTRAP_JAVAC_FLAGS (the SA command line may need to include both >>> -source and -target). ?At least try it, I think it'll be a simpler change. >> > > Ok, I must have missed this. ?It sounds a good idea and in the long > term I presume we want to get rid of the SA overrides anyway. > >> -John >> >> > > > > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Mon Sep 7 15:40:01 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 7 Sep 2009 23:40:01 +0100 Subject: [PATCH FOR REVIEW]: Fix warning in src/share/vm/adlc/archDesc.cpp In-Reply-To: <17c6771e0909060640w75fa3da3x8bcf0c387b1c151@mail.gmail.com> References: <17c6771e0909041518h20c4c809x27db9f5823896795@mail.gmail.com> <4AA197B0.10008@sun.com> <17c6771e0909041625xe756218l936ae08a84428b3e@mail.gmail.com> <4AA223EC.1010802@Sun.COM> <4AA22864.6020202@Sun.COM> <4AA24D4F.2010908@sun.com> <17c6771e0909060640w75fa3da3x8bcf0c387b1c151@mail.gmail.com> Message-ID: <17c6771e0909071540s5d86de45k538b4ddebdeb3fa9@mail.gmail.com> 2009/9/6 Andrew John Hughes : > 2009/9/5 David Holmes - Sun Microsystems : >> Christian Thalinger said the following on 09/05/09 18:59: >>> >>> Well, looking more closely it's actually a system header attribute that >>> brings up that warning: >>> >>> >>> /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp:1034: >>> error: ignoring return value of 'size_t fwrite(const void*, size_t, >>> size_t, FILE*)', declared with attribute warn_unused_result >>> >>> And it seems there is no GCC switch to turn that warning off (except >>> -O0). ?Maybe we should check for the written bytes to be the same as >>> requested: >>> >>> ?assert(count == size, "copyright info truncated"); >> >> I recall this coming up in the past. gcc manual lists: >> >> -Wno-unused-result >> >> but that might be version specific. >> >> David >> > > It's a very recent addition: > > http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00474.html > > which means there is a period (which includes GCC 4.4) where the > warning is produced but can't be disabled :( > > BTW, my current approach was influenced by > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/2328d1d3f8cf where > the same fix is applied to remove this warning. > I have to say I personally prefer twisti's assert fix and can apply > this if others are in agreement. > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > This is interesting; that assertion fails: g++ -m64 -Xlinker -O1 -m64 -export-dynamic -o ../generated/adfiles/adlc ../generated/adfiles/adlparse.o ../generated/adfiles/archDesc.o ../generated/adfiles/arena.o ../generated/adfiles/dfa.o ../generated/adfiles/dict2.o ../generated/adfiles/filebuff.o ../generated/adfiles/forms.o ../generated/adfiles/formsopt.o ../generated/adfiles/formssel.o ../generated/adfiles/main.o ../generated/adfiles/adlc-opcodes.o ../generated/adfiles/output_c.o ../generated/adfiles/output_h.o ../generated/adfiles/adlc -DLINUX -D_GNU_SOURCE -DAMD64 -q -T -D_LP64 ../generated/adfiles/linux_x86_64.ad \ -c../generated/adfiles/mktmp11816/ad_x86_64.cpp -h../generated/adfiles/mktmp11816/ad_x86_64.hpp -a../generated/adfiles/mktmp11816/dfa_x86_64.cpp -v../generated/adfiles/mktmp11816/adGlobals_x86_64.hpp \ || { rm -rf ../generated/adfiles/mktmp11816; exit 1; } assert fails /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp 1035: copyright info truncated /bin/sh: line 2: 12016 Aborted ../generated/adfiles/adlc -DLINUX -D_GNU_SOURCE -DAMD64 -q -T -D_LP64 ../generated/adfiles/linux_x86_64.ad -c../generated/adfiles/mktmp11816/ad_x86_64.cpp -h../generated/adfiles/mktmp11816/ad_x86_64.hpp -a../generated/adfiles/mktmp11816/dfa_x86_64.cpp -v../generated/adfiles/mktmp11816/adGlobals_x86_64.hpp make[7]: *** [refresh_adfiles] Error 1 -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From schlosna at gmail.com Mon Sep 7 16:53:44 2009 From: schlosna at gmail.com (David Schlosnagle) Date: Mon, 7 Sep 2009 19:53:44 -0400 Subject: [PATCH FOR REVIEW]: Fix warning in src/share/vm/adlc/archDesc.cpp In-Reply-To: <17c6771e0909071540s5d86de45k538b4ddebdeb3fa9@mail.gmail.com> References: <17c6771e0909041518h20c4c809x27db9f5823896795@mail.gmail.com> <4AA197B0.10008@sun.com> <17c6771e0909041625xe756218l936ae08a84428b3e@mail.gmail.com> <4AA223EC.1010802@Sun.COM> <4AA22864.6020202@Sun.COM> <4AA24D4F.2010908@sun.com> <17c6771e0909060640w75fa3da3x8bcf0c387b1c151@mail.gmail.com> <17c6771e0909071540s5d86de45k538b4ddebdeb3fa9@mail.gmail.com> Message-ID: <9146341c0909071653u6ca39196w91989a43880d2107@mail.gmail.com> Andrew, It seems like the warning and assert actually pointed out an existing bug -- the second and third arguments to fwrite seem to be swapped. The second arg should be the size (1 for char) and the third argument should is the number of items to write. The following should work: //---------------------------addSUNcopyright------------------------------- // output SUN copyright info void ArchDesc::addSunCopyright(char* legal, int size, FILE *fp) { - fwrite(legal, size, 1, fp); + size_t count = fwrite(legal, 1, size, fp); + assert(count == size, "copyright info truncated"); fprintf(fp,"\n"); fprintf(fp,"// Machine Generated File. Do Not Edit!\n"); fprintf(fp,"\n"); } >From : Synopsis #include size_t fwrite(const void *ptr, size_t size, size_t nitems, FILE *stream); Description The fwrite() function writes, from the array pointed to by ptr, up to nitems elements whose size is specified by size, to the stream pointed to by stream. For each object, size calls are made to the fputc(3C) function, taking the values (in order) from an array of unsigned char exactly overlaying the object. The file-position indicator for the stream (if defined) is advanced by the number of bytes successfully written. If an error occurs, the resulting value of the file-position indicator for the stream is unspecified. The st_ctime and st_mtime fields of the file will be marked for update between the successful execution of fwrite() and the next successful completion of a call to fflush(3C) or fclose(3C) on the same stream or a call to exit(2) or abort(3C). Return Values The fwrite() function returns the number of elements successfully written, which might be less than nitems if a write error is encountered. If size or nitems is 0, fwrite() returns 0 and the state of the stream remains unchanged. Otherwise, if a write error occurs, the error indicator for the stream is set and errno is set to indicate the error. Thanks, David Schlosnagle On Mon, Sep 7, 2009 at 6:40 PM, Andrew John Hughes wrote: > > 2009/9/6 Andrew John Hughes : > > 2009/9/5 David Holmes - Sun Microsystems : > >> Christian Thalinger said the following on 09/05/09 18:59: > >>> > >>> Well, looking more closely it's actually a system header attribute that > >>> brings up that warning: > >>> > >>> > >>> /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp:1034: > >>> error: ignoring return value of 'size_t fwrite(const void*, size_t, > >>> size_t, FILE*)', declared with attribute warn_unused_result > >>> > >>> And it seems there is no GCC switch to turn that warning off (except > >>> -O0). ?Maybe we should check for the written bytes to be the same as > >>> requested: > >>> > >>> ?assert(count == size, "copyright info truncated"); > >> > >> I recall this coming up in the past. gcc manual lists: > >> > >> -Wno-unused-result > >> > >> but that might be version specific. > >> > >> David > >> > > > > It's a very recent addition: > > > > http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00474.html > > > > which means there is a period (which includes GCC 4.4) where the > > warning is produced but can't be disabled :( > > > > BTW, my current approach was influenced by > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/2328d1d3f8cf where > > the same fix is applied to remove this warning. > > I have to say I personally prefer twisti's assert fix and can apply > > this if others are in agreement. > > -- > > Andrew :-) > > > > Free Java Software Engineer > > Red Hat, Inc. (http://www.redhat.com) > > > > Support Free Java! > > Contribute to GNU Classpath and the OpenJDK > > http://www.gnu.org/software/classpath > > http://openjdk.java.net > > > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > > > > This is interesting; that assertion fails: > > g++ -m64 -Xlinker -O1 ?-m64 -export-dynamic -o > ../generated/adfiles/adlc ../generated/adfiles/adlparse.o > ../generated/adfiles/archDesc.o ../generated/adfiles/arena.o > ../generated/adfiles/dfa.o ../generated/adfiles/dict2.o > ../generated/adfiles/filebuff.o ../generated/adfiles/forms.o > ../generated/adfiles/formsopt.o ../generated/adfiles/formssel.o > ../generated/adfiles/main.o ../generated/adfiles/adlc-opcodes.o > ../generated/adfiles/output_c.o ../generated/adfiles/output_h.o > ../generated/adfiles/adlc -DLINUX -D_GNU_SOURCE -DAMD64 -q -T -D_LP64 > ../generated/adfiles/linux_x86_64.ad ?\ > ?-c../generated/adfiles/mktmp11816/ad_x86_64.cpp > -h../generated/adfiles/mktmp11816/ad_x86_64.hpp > -a../generated/adfiles/mktmp11816/dfa_x86_64.cpp > -v../generated/adfiles/mktmp11816/adGlobals_x86_64.hpp \ > ? ? ? ? ? ?|| { rm -rf ../generated/adfiles/mktmp11816; exit 1; } > assert fails /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp > 1035: copyright info truncated > /bin/sh: line 2: 12016 Aborted > ../generated/adfiles/adlc -DLINUX -D_GNU_SOURCE -DAMD64 -q -T -D_LP64 > ../generated/adfiles/linux_x86_64.ad > -c../generated/adfiles/mktmp11816/ad_x86_64.cpp > -h../generated/adfiles/mktmp11816/ad_x86_64.hpp > -a../generated/adfiles/mktmp11816/dfa_x86_64.cpp > -v../generated/adfiles/mktmp11816/adGlobals_x86_64.hpp > make[7]: *** [refresh_adfiles] Error 1 > > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 From David.Holmes at Sun.COM Mon Sep 7 17:32:41 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Tue, 08 Sep 2009 10:32:41 +1000 Subject: [PATCH FOR REVIEW]: Fix warning in src/share/vm/adlc/archDesc.cpp In-Reply-To: <9146341c0909071653u6ca39196w91989a43880d2107@mail.gmail.com> References: <17c6771e0909041518h20c4c809x27db9f5823896795@mail.gmail.com> <4AA197B0.10008@sun.com> <17c6771e0909041625xe756218l936ae08a84428b3e@mail.gmail.com> <4AA223EC.1010802@Sun.COM> <4AA22864.6020202@Sun.COM> <4AA24D4F.2010908@sun.com> <17c6771e0909060640w75fa3da3x8bcf0c387b1c151@mail.gmail.com> <17c6771e0909071540s5d86de45k538b4ddebdeb3fa9@mail.gmail.com> <9146341c0909071653u6ca39196w91989a43880d2107@mail.gmail.com> Message-ID: <4AA5A629.5020106@sun.com> David, David Schlosnagle said the following on 09/08/09 09:53: > It seems like the warning and assert actually pointed out an existing > bug -- the second and third arguments to fwrite seem to be swapped. > The second arg should be the size (1 for char) and the third argument > should is the number of items to write. I don't see how it makes a difference: size * 1 == 1 * size All fwrite will do, from what I've seen, is multiply the two to obtain the number of bytes to write. It may be that Andrew encountered this bug: [BZ #5998] http://sourceware.org/git/?p=glibc.git;a=commit;h=a7925a24fe104a2ab54fb8a6bdec1e5cf80a8db7 or maybe there really was an error writing the data out. Cheers, David Holmes > > The following should work: > //---------------------------addSUNcopyright------------------------------- > // output SUN copyright info > void ArchDesc::addSunCopyright(char* legal, int size, FILE *fp) { > - fwrite(legal, size, 1, fp); > + size_t count = fwrite(legal, 1, size, fp); > + assert(count == size, "copyright info truncated"); > fprintf(fp,"\n"); > fprintf(fp,"// Machine Generated File. Do Not Edit!\n"); > fprintf(fp,"\n"); > } > >>From : > Synopsis > #include > size_t fwrite(const void *ptr, size_t size, size_t nitems, FILE *stream); > > Description > The fwrite() function writes, from the array pointed to by ptr, up to > nitems elements whose size is specified by size, to the stream pointed to > by stream. For each object, size calls are made to the fputc(3C) function, > taking the values (in order) from an array of unsigned char exactly > overlaying the object. The file-position indicator for the stream (if > defined) is advanced by the number of bytes successfully written. If an > error occurs, the resulting value of the file-position indicator for the > stream is unspecified. > > The st_ctime and st_mtime fields of the file will be marked for update > between the successful execution of fwrite() and the next successful > completion of a call to fflush(3C) or fclose(3C) on the same stream or a > call to exit(2) or abort(3C). > > Return Values > The fwrite() function returns the number of elements successfully written, > which might be less than nitems if a write error is encountered. If size or > nitems is 0, fwrite() returns 0 and the state of the stream remains > unchanged. Otherwise, if a write error occurs, the error indicator for the > stream is set and errno is set to indicate the error. > > Thanks, > David Schlosnagle > > On Mon, Sep 7, 2009 at 6:40 PM, Andrew John Hughes > wrote: >> 2009/9/6 Andrew John Hughes : >>> 2009/9/5 David Holmes - Sun Microsystems : >>>> Christian Thalinger said the following on 09/05/09 18:59: >>>>> Well, looking more closely it's actually a system header attribute that >>>>> brings up that warning: >>>>> >>>>> >>>>> /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp:1034: >>>>> error: ignoring return value of 'size_t fwrite(const void*, size_t, >>>>> size_t, FILE*)', declared with attribute warn_unused_result >>>>> >>>>> And it seems there is no GCC switch to turn that warning off (except >>>>> -O0). Maybe we should check for the written bytes to be the same as >>>>> requested: >>>>> >>>>> assert(count == size, "copyright info truncated"); >>>> I recall this coming up in the past. gcc manual lists: >>>> >>>> -Wno-unused-result >>>> >>>> but that might be version specific. >>>> >>>> David >>>> >>> It's a very recent addition: >>> >>> http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00474.html >>> >>> which means there is a period (which includes GCC 4.4) where the >>> warning is produced but can't be disabled :( >>> >>> BTW, my current approach was influenced by >>> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/2328d1d3f8cf where >>> the same fix is applied to remove this warning. >>> I have to say I personally prefer twisti's assert fix and can apply >>> this if others are in agreement. >>> -- >>> Andrew :-) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>> >> This is interesting; that assertion fails: >> >> g++ -m64 -Xlinker -O1 -m64 -export-dynamic -o >> ../generated/adfiles/adlc ../generated/adfiles/adlparse.o >> ../generated/adfiles/archDesc.o ../generated/adfiles/arena.o >> ../generated/adfiles/dfa.o ../generated/adfiles/dict2.o >> ../generated/adfiles/filebuff.o ../generated/adfiles/forms.o >> ../generated/adfiles/formsopt.o ../generated/adfiles/formssel.o >> ../generated/adfiles/main.o ../generated/adfiles/adlc-opcodes.o >> ../generated/adfiles/output_c.o ../generated/adfiles/output_h.o >> ../generated/adfiles/adlc -DLINUX -D_GNU_SOURCE -DAMD64 -q -T -D_LP64 >> ../generated/adfiles/linux_x86_64.ad \ >> -c../generated/adfiles/mktmp11816/ad_x86_64.cpp >> -h../generated/adfiles/mktmp11816/ad_x86_64.hpp >> -a../generated/adfiles/mktmp11816/dfa_x86_64.cpp >> -v../generated/adfiles/mktmp11816/adGlobals_x86_64.hpp \ >> || { rm -rf ../generated/adfiles/mktmp11816; exit 1; } >> assert fails /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp >> 1035: copyright info truncated >> /bin/sh: line 2: 12016 Aborted >> ../generated/adfiles/adlc -DLINUX -D_GNU_SOURCE -DAMD64 -q -T -D_LP64 >> ../generated/adfiles/linux_x86_64.ad >> -c../generated/adfiles/mktmp11816/ad_x86_64.cpp >> -h../generated/adfiles/mktmp11816/ad_x86_64.hpp >> -a../generated/adfiles/mktmp11816/dfa_x86_64.cpp >> -v../generated/adfiles/mktmp11816/adGlobals_x86_64.hpp >> make[7]: *** [refresh_adfiles] Error 1 >> >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From David.Holmes at Sun.COM Mon Sep 7 17:37:33 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Tue, 08 Sep 2009 10:37:33 +1000 Subject: [PATCH FOR REVIEW]: Fix warning in src/share/vm/adlc/archDesc.cpp In-Reply-To: <4AA5A629.5020106@sun.com> References: <17c6771e0909041518h20c4c809x27db9f5823896795@mail.gmail.com> <4AA197B0.10008@sun.com> <17c6771e0909041625xe756218l936ae08a84428b3e@mail.gmail.com> <4AA223EC.1010802@Sun.COM> <4AA22864.6020202@Sun.COM> <4AA24D4F.2010908@sun.com> <17c6771e0909060640w75fa3da3x8bcf0c387b1c151@mail.gmail.com> <17c6771e0909071540s5d86de45k538b4ddebdeb3fa9@mail.gmail.com> <9146341c0909071653u6ca39196w91989a43880d2107@mail.gmail.com> <4AA5A629.5020106@sun.com> Message-ID: <4AA5A74D.8050000@sun.com> Doh! The assert is wrong: assert(count == size, "copyright info truncated"); should be: assert(count == 1, "copyright info truncated"); as fwrite returns the number of items written, not the number of bytes. Or, as David Schlosnagle pointed out, the assert would be correct if we reversed the "size" and "1" arguments passed to fwrite. David Holmes David Holmes - Sun Microsystems said the following on 09/08/09 10:32: > David, > > David Schlosnagle said the following on 09/08/09 09:53: >> It seems like the warning and assert actually pointed out an existing >> bug -- the second and third arguments to fwrite seem to be swapped. >> The second arg should be the size (1 for char) and the third argument >> should is the number of items to write. > > I don't see how it makes a difference: size * 1 == 1 * size > > All fwrite will do, from what I've seen, is multiply the two to obtain > the number of bytes to write. > > It may be that Andrew encountered this bug: [BZ #5998] > > http://sourceware.org/git/?p=glibc.git;a=commit;h=a7925a24fe104a2ab54fb8a6bdec1e5cf80a8db7 > > > or maybe there really was an error writing the data out. > > Cheers, > David Holmes > >> >> The following should work: >> //---------------------------addSUNcopyright------------------------------- >> >> // output SUN copyright info >> void ArchDesc::addSunCopyright(char* legal, int size, FILE *fp) { >> - fwrite(legal, size, 1, fp); >> + size_t count = fwrite(legal, 1, size, fp); >> + assert(count == size, "copyright info truncated"); >> fprintf(fp,"\n"); >> fprintf(fp,"// Machine Generated File. Do Not Edit!\n"); >> fprintf(fp,"\n"); >> } >> >>> From : >> Synopsis >> #include >> size_t fwrite(const void *ptr, size_t size, size_t nitems, FILE >> *stream); >> >> Description >> The fwrite() function writes, from the array pointed to by ptr, up to >> nitems elements whose size is specified by size, to the stream >> pointed to >> by stream. For each object, size calls are made to the fputc(3C) >> function, >> taking the values (in order) from an array of unsigned char exactly >> overlaying the object. The file-position indicator for the stream (if >> defined) is advanced by the number of bytes successfully written. >> If an >> error occurs, the resulting value of the file-position indicator >> for the >> stream is unspecified. >> >> The st_ctime and st_mtime fields of the file will be marked for >> update >> between the successful execution of fwrite() and the next successful >> completion of a call to fflush(3C) or fclose(3C) on the same >> stream or a >> call to exit(2) or abort(3C). >> >> Return Values >> The fwrite() function returns the number of elements successfully >> written, >> which might be less than nitems if a write error is encountered. >> If size or >> nitems is 0, fwrite() returns 0 and the state of the stream remains >> unchanged. Otherwise, if a write error occurs, the error indicator >> for the >> stream is set and errno is set to indicate the error. >> >> Thanks, >> David Schlosnagle >> >> On Mon, Sep 7, 2009 at 6:40 PM, Andrew John Hughes >> wrote: >>> 2009/9/6 Andrew John Hughes : >>>> 2009/9/5 David Holmes - Sun Microsystems : >>>>> Christian Thalinger said the following on 09/05/09 18:59: >>>>>> Well, looking more closely it's actually a system header attribute >>>>>> that >>>>>> brings up that warning: >>>>>> >>>>>> >>>>>> /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp:1034: >>>>>> >>>>>> error: ignoring return value of 'size_t fwrite(const void*, size_t, >>>>>> size_t, FILE*)', declared with attribute warn_unused_result >>>>>> >>>>>> And it seems there is no GCC switch to turn that warning off (except >>>>>> -O0). Maybe we should check for the written bytes to be the same as >>>>>> requested: >>>>>> >>>>>> assert(count == size, "copyright info truncated"); >>>>> I recall this coming up in the past. gcc manual lists: >>>>> >>>>> -Wno-unused-result >>>>> >>>>> but that might be version specific. >>>>> >>>>> David >>>>> >>>> It's a very recent addition: >>>> >>>> http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00474.html >>>> >>>> which means there is a period (which includes GCC 4.4) where the >>>> warning is produced but can't be disabled :( >>>> >>>> BTW, my current approach was influenced by >>>> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/2328d1d3f8cf where >>>> the same fix is applied to remove this warning. >>>> I have to say I personally prefer twisti's assert fix and can apply >>>> this if others are in agreement. >>>> -- >>>> Andrew :-) >>>> >>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> Support Free Java! >>>> Contribute to GNU Classpath and the OpenJDK >>>> http://www.gnu.org/software/classpath >>>> http://openjdk.java.net >>>> >>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>> >>> This is interesting; that assertion fails: >>> >>> g++ -m64 -Xlinker -O1 -m64 -export-dynamic -o >>> ../generated/adfiles/adlc ../generated/adfiles/adlparse.o >>> ../generated/adfiles/archDesc.o ../generated/adfiles/arena.o >>> ../generated/adfiles/dfa.o ../generated/adfiles/dict2.o >>> ../generated/adfiles/filebuff.o ../generated/adfiles/forms.o >>> ../generated/adfiles/formsopt.o ../generated/adfiles/formssel.o >>> ../generated/adfiles/main.o ../generated/adfiles/adlc-opcodes.o >>> ../generated/adfiles/output_c.o ../generated/adfiles/output_h.o >>> ../generated/adfiles/adlc -DLINUX -D_GNU_SOURCE -DAMD64 -q -T -D_LP64 >>> ../generated/adfiles/linux_x86_64.ad \ >>> -c../generated/adfiles/mktmp11816/ad_x86_64.cpp >>> -h../generated/adfiles/mktmp11816/ad_x86_64.hpp >>> -a../generated/adfiles/mktmp11816/dfa_x86_64.cpp >>> -v../generated/adfiles/mktmp11816/adGlobals_x86_64.hpp \ >>> || { rm -rf ../generated/adfiles/mktmp11816; exit 1; } >>> assert fails >>> /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp >>> 1035: copyright info truncated >>> /bin/sh: line 2: 12016 Aborted >>> ../generated/adfiles/adlc -DLINUX -D_GNU_SOURCE -DAMD64 -q -T -D_LP64 >>> ../generated/adfiles/linux_x86_64.ad >>> -c../generated/adfiles/mktmp11816/ad_x86_64.cpp >>> -h../generated/adfiles/mktmp11816/ad_x86_64.hpp >>> -a../generated/adfiles/mktmp11816/dfa_x86_64.cpp >>> -v../generated/adfiles/mktmp11816/adGlobals_x86_64.hpp >>> make[7]: *** [refresh_adfiles] Error 1 >>> >>> -- >>> Andrew :-) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Mon Sep 7 17:51:01 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Sep 2009 01:51:01 +0100 Subject: [PATCH FOR REVIEW]: Fix warning in src/share/vm/adlc/archDesc.cpp In-Reply-To: <4AA5A74D.8050000@sun.com> References: <17c6771e0909041518h20c4c809x27db9f5823896795@mail.gmail.com> <17c6771e0909041625xe756218l936ae08a84428b3e@mail.gmail.com> <4AA223EC.1010802@Sun.COM> <4AA22864.6020202@Sun.COM> <4AA24D4F.2010908@sun.com> <17c6771e0909060640w75fa3da3x8bcf0c387b1c151@mail.gmail.com> <17c6771e0909071540s5d86de45k538b4ddebdeb3fa9@mail.gmail.com> <9146341c0909071653u6ca39196w91989a43880d2107@mail.gmail.com> <4AA5A629.5020106@sun.com> <4AA5A74D.8050000@sun.com> Message-ID: <17c6771e0909071751o2b60a3d5ma02f88e2cb50ae73@mail.gmail.com> 2009/9/8 David Holmes - Sun Microsystems : > Doh! The assert is wrong: > > assert(count == size, "copyright info truncated"); > > should be: > > assert(count == 1, "copyright info truncated"); > > as fwrite returns the number of items written, not the number of bytes. > > Or, as David Schlosnagle pointed out, the assert would be correct if we > reversed the "size" and "1" arguments passed to fwrite. > Yeah, the assert or the fwrite call are wrong, depending on which way you look at it. Generally, you'd want to check that all the characters were written out, rather than checking that it returns 1, so I think the assert is right and the fwrite should be changed. That's what the webrev: http://cr.openjdk.java.net/~andrew/werror/webrev.02/ does. As you say, it's not really a bug; the files are generated correctly as most fwrite implementations are just going to calculate the total size by multiplying the two values and multiplication is commutative. But it's nice that fixing the warning by adding a check does catch this, and if fwrite ever fails, we now won't ignore it. Ok to push? If so, I need a bug ID for it :) > David Holmes > > David Holmes - Sun Microsystems said the following on 09/08/09 10:32: >> >> David, >> >> David Schlosnagle said the following on 09/08/09 09:53: >>> >>> It seems like the warning and assert actually pointed out an existing >>> bug -- the second and third arguments to fwrite seem to be swapped. >>> The second arg should be the size (1 for char) and the third argument >>> should is the number of items to write. >> >> I don't see how it makes a difference: size * 1 == 1 * size >> >> All fwrite will do, from what I've seen, is multiply the two to obtain the >> number of bytes to write. >> >> It may be that Andrew encountered this bug: [BZ #5998] >> >> >> http://sourceware.org/git/?p=glibc.git;a=commit;h=a7925a24fe104a2ab54fb8a6bdec1e5cf80a8db7 >> >> or maybe there really was an error writing the data out. >> >> Cheers, >> David Holmes >> >>> >>> The following should work: >>> >>> //---------------------------addSUNcopyright------------------------------- >>> ?// output SUN copyright info >>> ?void ArchDesc::addSunCopyright(char* legal, int size, FILE *fp) { >>> - ?fwrite(legal, size, 1, fp); >>> + ?size_t count = fwrite(legal, 1, size, fp); >>> + ?assert(count == size, "copyright info truncated"); >>> ? fprintf(fp,"\n"); >>> ? fprintf(fp,"// Machine Generated File. ?Do Not Edit!\n"); >>> ? fprintf(fp,"\n"); >>> ?} >>> >>>> From : >>> >>> Synopsis >>> ? ?#include >>> ? ?size_t fwrite(const void *ptr, size_t size, size_t nitems, FILE >>> *stream); >>> >>> Description >>> ? ?The fwrite() function writes, from the array pointed to by ptr, up to >>> ? ?nitems elements whose size is specified by size, to the stream pointed >>> to >>> ? ?by stream. For each object, size calls are made to the fputc(3C) >>> function, >>> ? ?taking the values (in order) from an array of unsigned char exactly >>> ? ?overlaying the object. The file-position indicator for the stream (if >>> ? ?defined) is advanced by the number of bytes successfully written. If >>> an >>> ? ?error occurs, the resulting value of the file-position indicator for >>> the >>> ? ?stream is unspecified. >>> >>> ? ?The st_ctime and st_mtime fields of the file will be marked for update >>> ? ?between the successful execution of fwrite() and the next successful >>> ? ?completion of a call to fflush(3C) or fclose(3C) on the same stream or >>> a >>> ? ?call to exit(2) or abort(3C). >>> >>> Return Values >>> ? ?The fwrite() function returns the number of elements successfully >>> written, >>> ? ?which might be less than nitems if a write error is encountered. If >>> size or >>> ? ?nitems is 0, fwrite() returns 0 and the state of the stream remains >>> ? ?unchanged. Otherwise, if a write error occurs, the error indicator for >>> the >>> ? ?stream is set and errno is set to indicate the error. >>> >>> Thanks, >>> David Schlosnagle >>> >>> On Mon, Sep 7, 2009 at 6:40 PM, Andrew John Hughes >>> wrote: >>>> >>>> 2009/9/6 Andrew John Hughes : >>>>> >>>>> 2009/9/5 David Holmes - Sun Microsystems : >>>>>> >>>>>> Christian Thalinger said the following on 09/05/09 18:59: >>>>>>> >>>>>>> Well, looking more closely it's actually a system header attribute >>>>>>> that >>>>>>> brings up that warning: >>>>>>> >>>>>>> >>>>>>> >>>>>>> /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp:1034: >>>>>>> error: ignoring return value of 'size_t fwrite(const void*, size_t, >>>>>>> size_t, FILE*)', declared with attribute warn_unused_result >>>>>>> >>>>>>> And it seems there is no GCC switch to turn that warning off (except >>>>>>> -O0). ?Maybe we should check for the written bytes to be the same as >>>>>>> requested: >>>>>>> >>>>>>> ?assert(count == size, "copyright info truncated"); >>>>>> >>>>>> I recall this coming up in the past. gcc manual lists: >>>>>> >>>>>> -Wno-unused-result >>>>>> >>>>>> but that might be version specific. >>>>>> >>>>>> David >>>>>> >>>>> It's a very recent addition: >>>>> >>>>> http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00474.html >>>>> >>>>> which means there is a period (which includes GCC 4.4) where the >>>>> warning is produced but can't be disabled :( >>>>> >>>>> BTW, my current approach was influenced by >>>>> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/2328d1d3f8cf where >>>>> the same fix is applied to remove this warning. >>>>> I have to say I personally prefer twisti's assert fix and can apply >>>>> this if others are in agreement. >>>>> -- >>>>> Andrew :-) >>>>> >>>>> Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> Support Free Java! >>>>> Contribute to GNU Classpath and the OpenJDK >>>>> http://www.gnu.org/software/classpath >>>>> http://openjdk.java.net >>>>> >>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>>> >>>> This is interesting; that assertion fails: >>>> >>>> g++ -m64 -Xlinker -O1 ?-m64 -export-dynamic -o >>>> ../generated/adfiles/adlc ../generated/adfiles/adlparse.o >>>> ../generated/adfiles/archDesc.o ../generated/adfiles/arena.o >>>> ../generated/adfiles/dfa.o ../generated/adfiles/dict2.o >>>> ../generated/adfiles/filebuff.o ../generated/adfiles/forms.o >>>> ../generated/adfiles/formsopt.o ../generated/adfiles/formssel.o >>>> ../generated/adfiles/main.o ../generated/adfiles/adlc-opcodes.o >>>> ../generated/adfiles/output_c.o ../generated/adfiles/output_h.o >>>> ../generated/adfiles/adlc -DLINUX -D_GNU_SOURCE -DAMD64 -q -T -D_LP64 >>>> ../generated/adfiles/linux_x86_64.ad ?\ >>>> ?-c../generated/adfiles/mktmp11816/ad_x86_64.cpp >>>> -h../generated/adfiles/mktmp11816/ad_x86_64.hpp >>>> -a../generated/adfiles/mktmp11816/dfa_x86_64.cpp >>>> -v../generated/adfiles/mktmp11816/adGlobals_x86_64.hpp \ >>>> ? ? ? ? ? || { rm -rf ../generated/adfiles/mktmp11816; exit 1; } >>>> assert fails >>>> /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp >>>> 1035: copyright info truncated >>>> /bin/sh: line 2: 12016 Aborted >>>> ../generated/adfiles/adlc -DLINUX -D_GNU_SOURCE -DAMD64 -q -T -D_LP64 >>>> ../generated/adfiles/linux_x86_64.ad >>>> -c../generated/adfiles/mktmp11816/ad_x86_64.cpp >>>> -h../generated/adfiles/mktmp11816/ad_x86_64.hpp >>>> -a../generated/adfiles/mktmp11816/dfa_x86_64.cpp >>>> -v../generated/adfiles/mktmp11816/adGlobals_x86_64.hpp >>>> make[7]: *** [refresh_adfiles] Error 1 >>>> >>>> -- >>>> Andrew :-) >>>> >>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> Support Free Java! >>>> Contribute to GNU Classpath and the OpenJDK >>>> http://www.gnu.org/software/classpath >>>> http://openjdk.java.net >>>> >>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From David.Holmes at Sun.COM Mon Sep 7 18:13:11 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Tue, 08 Sep 2009 11:13:11 +1000 Subject: [PATCH FOR REVIEW]: Fix warning in src/share/vm/adlc/archDesc.cpp In-Reply-To: <17c6771e0909071751o2b60a3d5ma02f88e2cb50ae73@mail.gmail.com> References: <17c6771e0909041518h20c4c809x27db9f5823896795@mail.gmail.com> <17c6771e0909041625xe756218l936ae08a84428b3e@mail.gmail.com> <4AA223EC.1010802@Sun.COM> <4AA22864.6020202@Sun.COM> <4AA24D4F.2010908@sun.com> <17c6771e0909060640w75fa3da3x8bcf0c387b1c151@mail.gmail.com> <17c6771e0909071540s5d86de45k538b4ddebdeb3fa9@mail.gmail.com> <9146341c0909071653u6ca39196w91989a43880d2107@mail.gmail.com> <4AA5A629.5020106@sun.com> <4AA5A74D.8050000@sun.com> <17c6771e0909071751o2b60a3d5ma02f88e2cb50ae73@mail.gmail.com> Message-ID: <4AA5AFA7.1000205@sun.com> Andrew, Andrew John Hughes said the following on 09/08/09 10:51: > 2009/9/8 David Holmes - Sun Microsystems : >> Doh! The assert is wrong: >> >> assert(count == size, "copyright info truncated"); >> >> should be: >> >> assert(count == 1, "copyright info truncated"); >> >> as fwrite returns the number of items written, not the number of bytes. >> >> Or, as David Schlosnagle pointed out, the assert would be correct if we >> reversed the "size" and "1" arguments passed to fwrite. >> > > Yeah, the assert or the fwrite call are wrong, depending on which way > you look at it. Generally, you'd want to check that all the > characters were written out, rather than checking that it returns 1, > so I think the assert is right and the fwrite should be changed. > That's what the webrev: > > http://cr.openjdk.java.net/~andrew/werror/webrev.02/ > > does. Doesn't this: void ArchDesc::addSunCopyright(char* legal, int size, FILE *fp) { ! size_t count = fwrite(legal, 1, size, fp); ! assert(count == size, "copyright info truncated"); generate a signed vs. unsigned comparison warning ? > But it's nice that fixing the warning by adding a check > does catch this, and if fwrite ever fails, we now won't ignore it. > > Ok to push? I guess that as this is only a build-time issue then using the assert is ok. But the cynic in me won't be surprised if we find we get unexpected failures. That said, I'm not even sure if assertions are enabled during the build process ... > If so, I need a bug ID for it :) 6879689 (hope I did it right! not quite sure of the protocol for these :) ) David Holmes >> David Holmes >> >> David Holmes - Sun Microsystems said the following on 09/08/09 10:32: >>> David, >>> >>> David Schlosnagle said the following on 09/08/09 09:53: >>>> It seems like the warning and assert actually pointed out an existing >>>> bug -- the second and third arguments to fwrite seem to be swapped. >>>> The second arg should be the size (1 for char) and the third argument >>>> should is the number of items to write. >>> I don't see how it makes a difference: size * 1 == 1 * size >>> >>> All fwrite will do, from what I've seen, is multiply the two to obtain the >>> number of bytes to write. >>> >>> It may be that Andrew encountered this bug: [BZ #5998] >>> >>> >>> http://sourceware.org/git/?p=glibc.git;a=commit;h=a7925a24fe104a2ab54fb8a6bdec1e5cf80a8db7 >>> >>> or maybe there really was an error writing the data out. >>> >>> Cheers, >>> David Holmes >>> >>>> The following should work: >>>> >>>> //---------------------------addSUNcopyright------------------------------- >>>> // output SUN copyright info >>>> void ArchDesc::addSunCopyright(char* legal, int size, FILE *fp) { >>>> - fwrite(legal, size, 1, fp); >>>> + size_t count = fwrite(legal, 1, size, fp); >>>> + assert(count == size, "copyright info truncated"); >>>> fprintf(fp,"\n"); >>>> fprintf(fp,"// Machine Generated File. Do Not Edit!\n"); >>>> fprintf(fp,"\n"); >>>> } >>>> >>>>> From : >>>> Synopsis >>>> #include >>>> size_t fwrite(const void *ptr, size_t size, size_t nitems, FILE >>>> *stream); >>>> >>>> Description >>>> The fwrite() function writes, from the array pointed to by ptr, up to >>>> nitems elements whose size is specified by size, to the stream pointed >>>> to >>>> by stream. For each object, size calls are made to the fputc(3C) >>>> function, >>>> taking the values (in order) from an array of unsigned char exactly >>>> overlaying the object. The file-position indicator for the stream (if >>>> defined) is advanced by the number of bytes successfully written. If >>>> an >>>> error occurs, the resulting value of the file-position indicator for >>>> the >>>> stream is unspecified. >>>> >>>> The st_ctime and st_mtime fields of the file will be marked for update >>>> between the successful execution of fwrite() and the next successful >>>> completion of a call to fflush(3C) or fclose(3C) on the same stream or >>>> a >>>> call to exit(2) or abort(3C). >>>> >>>> Return Values >>>> The fwrite() function returns the number of elements successfully >>>> written, >>>> which might be less than nitems if a write error is encountered. If >>>> size or >>>> nitems is 0, fwrite() returns 0 and the state of the stream remains >>>> unchanged. Otherwise, if a write error occurs, the error indicator for >>>> the >>>> stream is set and errno is set to indicate the error. >>>> >>>> Thanks, >>>> David Schlosnagle >>>> >>>> On Mon, Sep 7, 2009 at 6:40 PM, Andrew John Hughes >>>> wrote: >>>>> 2009/9/6 Andrew John Hughes : >>>>>> 2009/9/5 David Holmes - Sun Microsystems : >>>>>>> Christian Thalinger said the following on 09/05/09 18:59: >>>>>>>> Well, looking more closely it's actually a system header attribute >>>>>>>> that >>>>>>>> brings up that warning: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp:1034: >>>>>>>> error: ignoring return value of 'size_t fwrite(const void*, size_t, >>>>>>>> size_t, FILE*)', declared with attribute warn_unused_result >>>>>>>> >>>>>>>> And it seems there is no GCC switch to turn that warning off (except >>>>>>>> -O0). Maybe we should check for the written bytes to be the same as >>>>>>>> requested: >>>>>>>> >>>>>>>> assert(count == size, "copyright info truncated"); >>>>>>> I recall this coming up in the past. gcc manual lists: >>>>>>> >>>>>>> -Wno-unused-result >>>>>>> >>>>>>> but that might be version specific. >>>>>>> >>>>>>> David >>>>>>> >>>>>> It's a very recent addition: >>>>>> >>>>>> http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00474.html >>>>>> >>>>>> which means there is a period (which includes GCC 4.4) where the >>>>>> warning is produced but can't be disabled :( >>>>>> >>>>>> BTW, my current approach was influenced by >>>>>> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/2328d1d3f8cf where >>>>>> the same fix is applied to remove this warning. >>>>>> I have to say I personally prefer twisti's assert fix and can apply >>>>>> this if others are in agreement. >>>>>> -- >>>>>> Andrew :-) >>>>>> >>>>>> Free Java Software Engineer >>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>> >>>>>> Support Free Java! >>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>> http://www.gnu.org/software/classpath >>>>>> http://openjdk.java.net >>>>>> >>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>> >>>>> This is interesting; that assertion fails: >>>>> >>>>> g++ -m64 -Xlinker -O1 -m64 -export-dynamic -o >>>>> ../generated/adfiles/adlc ../generated/adfiles/adlparse.o >>>>> ../generated/adfiles/archDesc.o ../generated/adfiles/arena.o >>>>> ../generated/adfiles/dfa.o ../generated/adfiles/dict2.o >>>>> ../generated/adfiles/filebuff.o ../generated/adfiles/forms.o >>>>> ../generated/adfiles/formsopt.o ../generated/adfiles/formssel.o >>>>> ../generated/adfiles/main.o ../generated/adfiles/adlc-opcodes.o >>>>> ../generated/adfiles/output_c.o ../generated/adfiles/output_h.o >>>>> ../generated/adfiles/adlc -DLINUX -D_GNU_SOURCE -DAMD64 -q -T -D_LP64 >>>>> ../generated/adfiles/linux_x86_64.ad \ >>>>> -c../generated/adfiles/mktmp11816/ad_x86_64.cpp >>>>> -h../generated/adfiles/mktmp11816/ad_x86_64.hpp >>>>> -a../generated/adfiles/mktmp11816/dfa_x86_64.cpp >>>>> -v../generated/adfiles/mktmp11816/adGlobals_x86_64.hpp \ >>>>> || { rm -rf ../generated/adfiles/mktmp11816; exit 1; } >>>>> assert fails >>>>> /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp >>>>> 1035: copyright info truncated >>>>> /bin/sh: line 2: 12016 Aborted >>>>> ../generated/adfiles/adlc -DLINUX -D_GNU_SOURCE -DAMD64 -q -T -D_LP64 >>>>> ../generated/adfiles/linux_x86_64.ad >>>>> -c../generated/adfiles/mktmp11816/ad_x86_64.cpp >>>>> -h../generated/adfiles/mktmp11816/ad_x86_64.hpp >>>>> -a../generated/adfiles/mktmp11816/dfa_x86_64.cpp >>>>> -v../generated/adfiles/mktmp11816/adGlobals_x86_64.hpp >>>>> make[7]: *** [refresh_adfiles] Error 1 >>>>> >>>>> -- >>>>> Andrew :-) >>>>> >>>>> Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> Support Free Java! >>>>> Contribute to GNU Classpath and the OpenJDK >>>>> http://www.gnu.org/software/classpath >>>>> http://openjdk.java.net >>>>> >>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > > > From gnu_andrew at member.fsf.org Mon Sep 7 18:35:08 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Sep 2009 02:35:08 +0100 Subject: [PATCH FOR REVIEW]: Fix warning in src/share/vm/adlc/archDesc.cpp In-Reply-To: <4AA5AFA7.1000205@sun.com> References: <17c6771e0909041518h20c4c809x27db9f5823896795@mail.gmail.com> <4AA22864.6020202@Sun.COM> <4AA24D4F.2010908@sun.com> <17c6771e0909060640w75fa3da3x8bcf0c387b1c151@mail.gmail.com> <17c6771e0909071540s5d86de45k538b4ddebdeb3fa9@mail.gmail.com> <9146341c0909071653u6ca39196w91989a43880d2107@mail.gmail.com> <4AA5A629.5020106@sun.com> <4AA5A74D.8050000@sun.com> <17c6771e0909071751o2b60a3d5ma02f88e2cb50ae73@mail.gmail.com> <4AA5AFA7.1000205@sun.com> Message-ID: <17c6771e0909071835h38256cc4g17f5df857cb2b921@mail.gmail.com> 2009/9/8 David Holmes - Sun Microsystems : > Andrew, > > Andrew John Hughes said the following on 09/08/09 10:51: >> >> 2009/9/8 David Holmes - Sun Microsystems : >>> >>> Doh! The assert is wrong: >>> >>> assert(count == size, "copyright info truncated"); >>> >>> should be: >>> >>> assert(count == 1, "copyright info truncated"); >>> >>> as fwrite returns the number of items written, not the number of bytes. >>> >>> Or, as David Schlosnagle pointed out, the assert would be correct if we >>> reversed the "size" and "1" arguments passed to fwrite. >>> >> >> Yeah, the assert or the fwrite call are wrong, depending on which way >> you look at it. ?Generally, you'd want to check that all the >> characters were written out, rather than checking that it returns 1, >> so I think the assert is right and the fwrite should be changed. >> That's what the webrev: >> >> http://cr.openjdk.java.net/~andrew/werror/webrev.02/ >> >> does. > > Doesn't this: > > ?void ArchDesc::addSunCopyright(char* legal, int size, FILE *fp) { > ! ? size_t count = fwrite(legal, 1, size, fp); > ! ? assert(count == size, "copyright info truncated"); > > generate a signed vs. unsigned comparison warning ? > Interestingly, it doesn't, even though int is signed and size_t is unsigned. That's a good point. I can add a cast of size to size_t to be on the safe side. That happens anyway in passing it to fwrite, as its arguments are const void*, size_t, size_t, FILE*. >> But it's nice that fixing the warning by adding a check >> does catch this, and if fwrite ever fails, we now won't ignore it. >> >> Ok to push? > > I guess that as this is only a build-time issue then using the assert is ok. > But the cynic in me won't be surprised if we find we get unexpected > failures. That said, I'm not even sure if assertions are enabled during > the build process ... > They are at some point, that's what caused the previous failure :) That also implies the code inside the assert is getting compiled. >> If so, I need a bug ID for it :) > > 6879689 (hope I did it right! not quite sure of the protocol for these :) ) > Thanks! If I create one as an external user, I'm told to wait three days. Last time, even that wasn't good enough and I had to get Dalibor to push some buttons internally. > David Holmes > >>> David Holmes >>> >>> David Holmes - Sun Microsystems said the following on 09/08/09 10:32: >>>> >>>> David, >>>> >>>> David Schlosnagle said the following on 09/08/09 09:53: >>>>> >>>>> It seems like the warning and assert actually pointed out an existing >>>>> bug -- the second and third arguments to fwrite seem to be swapped. >>>>> The second arg should be the size (1 for char) and the third argument >>>>> should is the number of items to write. >>>> >>>> I don't see how it makes a difference: size * 1 == 1 * size >>>> >>>> All fwrite will do, from what I've seen, is multiply the two to obtain >>>> the >>>> number of bytes to write. >>>> >>>> It may be that Andrew encountered this bug: [BZ #5998] >>>> >>>> >>>> >>>> http://sourceware.org/git/?p=glibc.git;a=commit;h=a7925a24fe104a2ab54fb8a6bdec1e5cf80a8db7 >>>> >>>> or maybe there really was an error writing the data out. >>>> >>>> Cheers, >>>> David Holmes >>>> >>>>> The following should work: >>>>> >>>>> >>>>> //---------------------------addSUNcopyright------------------------------- >>>>> ?// output SUN copyright info >>>>> ?void ArchDesc::addSunCopyright(char* legal, int size, FILE *fp) { >>>>> - ?fwrite(legal, size, 1, fp); >>>>> + ?size_t count = fwrite(legal, 1, size, fp); >>>>> + ?assert(count == size, "copyright info truncated"); >>>>> ?fprintf(fp,"\n"); >>>>> ?fprintf(fp,"// Machine Generated File. ?Do Not Edit!\n"); >>>>> ?fprintf(fp,"\n"); >>>>> ?} >>>>> >>>>>> From : >>>>> >>>>> Synopsis >>>>> ? #include >>>>> ? size_t fwrite(const void *ptr, size_t size, size_t nitems, FILE >>>>> *stream); >>>>> >>>>> Description >>>>> ? The fwrite() function writes, from the array pointed to by ptr, up to >>>>> ? nitems elements whose size is specified by size, to the stream >>>>> pointed >>>>> to >>>>> ? by stream. For each object, size calls are made to the fputc(3C) >>>>> function, >>>>> ? taking the values (in order) from an array of unsigned char exactly >>>>> ? overlaying the object. The file-position indicator for the stream (if >>>>> ? defined) is advanced by the number of bytes successfully written. If >>>>> an >>>>> ? error occurs, the resulting value of the file-position indicator for >>>>> the >>>>> ? stream is unspecified. >>>>> >>>>> ? The st_ctime and st_mtime fields of the file will be marked for >>>>> update >>>>> ? between the successful execution of fwrite() and the next successful >>>>> ? completion of a call to fflush(3C) or fclose(3C) on the same stream >>>>> or >>>>> a >>>>> ? call to exit(2) or abort(3C). >>>>> >>>>> Return Values >>>>> ? The fwrite() function returns the number of elements successfully >>>>> written, >>>>> ? which might be less than nitems if a write error is encountered. If >>>>> size or >>>>> ? nitems is 0, fwrite() returns 0 and the state of the stream remains >>>>> ? unchanged. Otherwise, if a write error occurs, the error indicator >>>>> for >>>>> the >>>>> ? stream is set and errno is set to indicate the error. >>>>> >>>>> Thanks, >>>>> David Schlosnagle >>>>> >>>>> On Mon, Sep 7, 2009 at 6:40 PM, Andrew John Hughes >>>>> wrote: >>>>>> >>>>>> 2009/9/6 Andrew John Hughes : >>>>>>> >>>>>>> 2009/9/5 David Holmes - Sun Microsystems : >>>>>>>> >>>>>>>> Christian Thalinger said the following on 09/05/09 18:59: >>>>>>>>> >>>>>>>>> Well, looking more closely it's actually a system header attribute >>>>>>>>> that >>>>>>>>> brings up that warning: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp:1034: >>>>>>>>> error: ignoring return value of 'size_t fwrite(const void*, size_t, >>>>>>>>> size_t, FILE*)', declared with attribute warn_unused_result >>>>>>>>> >>>>>>>>> And it seems there is no GCC switch to turn that warning off >>>>>>>>> (except >>>>>>>>> -O0). ?Maybe we should check for the written bytes to be the same >>>>>>>>> as >>>>>>>>> requested: >>>>>>>>> >>>>>>>>> ?assert(count == size, "copyright info truncated"); >>>>>>>> >>>>>>>> I recall this coming up in the past. gcc manual lists: >>>>>>>> >>>>>>>> -Wno-unused-result >>>>>>>> >>>>>>>> but that might be version specific. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>> It's a very recent addition: >>>>>>> >>>>>>> http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00474.html >>>>>>> >>>>>>> which means there is a period (which includes GCC 4.4) where the >>>>>>> warning is produced but can't be disabled :( >>>>>>> >>>>>>> BTW, my current approach was influenced by >>>>>>> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/2328d1d3f8cf where >>>>>>> the same fix is applied to remove this warning. >>>>>>> I have to say I personally prefer twisti's assert fix and can apply >>>>>>> this if others are in agreement. >>>>>>> -- >>>>>>> Andrew :-) >>>>>>> >>>>>>> Free Java Software Engineer >>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>> >>>>>>> Support Free Java! >>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>> http://www.gnu.org/software/classpath >>>>>>> http://openjdk.java.net >>>>>>> >>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>>>>> >>>>>> This is interesting; that assertion fails: >>>>>> >>>>>> g++ -m64 -Xlinker -O1 ?-m64 -export-dynamic -o >>>>>> ../generated/adfiles/adlc ../generated/adfiles/adlparse.o >>>>>> ../generated/adfiles/archDesc.o ../generated/adfiles/arena.o >>>>>> ../generated/adfiles/dfa.o ../generated/adfiles/dict2.o >>>>>> ../generated/adfiles/filebuff.o ../generated/adfiles/forms.o >>>>>> ../generated/adfiles/formsopt.o ../generated/adfiles/formssel.o >>>>>> ../generated/adfiles/main.o ../generated/adfiles/adlc-opcodes.o >>>>>> ../generated/adfiles/output_c.o ../generated/adfiles/output_h.o >>>>>> ../generated/adfiles/adlc -DLINUX -D_GNU_SOURCE -DAMD64 -q -T -D_LP64 >>>>>> ../generated/adfiles/linux_x86_64.ad ?\ >>>>>> ?-c../generated/adfiles/mktmp11816/ad_x86_64.cpp >>>>>> -h../generated/adfiles/mktmp11816/ad_x86_64.hpp >>>>>> -a../generated/adfiles/mktmp11816/dfa_x86_64.cpp >>>>>> -v../generated/adfiles/mktmp11816/adGlobals_x86_64.hpp \ >>>>>> ? ? ? ? ?|| { rm -rf ../generated/adfiles/mktmp11816; exit 1; } >>>>>> assert fails >>>>>> >>>>>> /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp >>>>>> 1035: copyright info truncated >>>>>> /bin/sh: line 2: 12016 Aborted >>>>>> ../generated/adfiles/adlc -DLINUX -D_GNU_SOURCE -DAMD64 -q -T -D_LP64 >>>>>> ../generated/adfiles/linux_x86_64.ad >>>>>> -c../generated/adfiles/mktmp11816/ad_x86_64.cpp >>>>>> -h../generated/adfiles/mktmp11816/ad_x86_64.hpp >>>>>> -a../generated/adfiles/mktmp11816/dfa_x86_64.cpp >>>>>> -v../generated/adfiles/mktmp11816/adGlobals_x86_64.hpp >>>>>> make[7]: *** [refresh_adfiles] Error 1 >>>>>> >>>>>> -- >>>>>> Andrew :-) >>>>>> >>>>>> Free Java Software Engineer >>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>> >>>>>> Support Free Java! >>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>> http://www.gnu.org/software/classpath >>>>>> http://openjdk.java.net >>>>>> >>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >> >> >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From schlosna at gmail.com Mon Sep 7 19:14:31 2009 From: schlosna at gmail.com (David Schlosnagle) Date: Mon, 7 Sep 2009 22:14:31 -0400 Subject: [PATCH FOR REVIEW]: Fix warning in src/share/vm/adlc/archDesc.cpp In-Reply-To: <17c6771e0909071835h38256cc4g17f5df857cb2b921@mail.gmail.com> References: <17c6771e0909041518h20c4c809x27db9f5823896795@mail.gmail.com> <4AA24D4F.2010908@sun.com> <17c6771e0909060640w75fa3da3x8bcf0c387b1c151@mail.gmail.com> <17c6771e0909071540s5d86de45k538b4ddebdeb3fa9@mail.gmail.com> <9146341c0909071653u6ca39196w91989a43880d2107@mail.gmail.com> <4AA5A629.5020106@sun.com> <4AA5A74D.8050000@sun.com> <17c6771e0909071751o2b60a3d5ma02f88e2cb50ae73@mail.gmail.com> <4AA5AFA7.1000205@sun.com> <17c6771e0909071835h38256cc4g17f5df857cb2b921@mail.gmail.com> Message-ID: <9146341c0909071914j6e3ed33eof667dad6dce88085@mail.gmail.com> Is it worthwhile to change the method signature to better identify its arguments? void ArchDesc::addSunCopyright(const char* legal, size_t size, FILE *fp) { size_t count = fwrite(legal, sizeof(char), size, fp); assert(count == size); fprintf(fp,"\n"); fprintf(fp,"// Machine Generated File. Do Not Edit!\n"); fprintf(fp,"\n"); } Its a slippery slope to start checking the return values on those I/O functions, and it doesn't look like anything else in that file is checking them. I'm definitely not the right person to say whether the assert is the proper error handling for this situation, but I'd assume the user should know that the files weren't able to be written (most likely due to some larger I/O problem) rather than fail silently. Thanks, Dave On Mon, Sep 7, 2009 at 9:35 PM, Andrew John Hughes wrote: > 2009/9/8 David Holmes - Sun Microsystems : >> Andrew, >> >> Andrew John Hughes said the following on 09/08/09 10:51: >>> >>> 2009/9/8 David Holmes - Sun Microsystems : >>>> >>>> Doh! The assert is wrong: >>>> >>>> assert(count == size, "copyright info truncated"); >>>> >>>> should be: >>>> >>>> assert(count == 1, "copyright info truncated"); >>>> >>>> as fwrite returns the number of items written, not the number of bytes. >>>> >>>> Or, as David Schlosnagle pointed out, the assert would be correct if we >>>> reversed the "size" and "1" arguments passed to fwrite. >>>> >>> >>> Yeah, the assert or the fwrite call are wrong, depending on which way >>> you look at it. ?Generally, you'd want to check that all the >>> characters were written out, rather than checking that it returns 1, >>> so I think the assert is right and the fwrite should be changed. >>> That's what the webrev: >>> >>> http://cr.openjdk.java.net/~andrew/werror/webrev.02/ >>> >>> does. >> >> Doesn't this: >> >> ?void ArchDesc::addSunCopyright(char* legal, int size, FILE *fp) { >> ! ? size_t count = fwrite(legal, 1, size, fp); >> ! ? assert(count == size, "copyright info truncated"); >> >> generate a signed vs. unsigned comparison warning ? >> > > Interestingly, it doesn't, even though int is signed and size_t is > unsigned. ?That's a good point. > I can add a cast of size to size_t to be on the safe side. ?That > happens anyway in passing it to fwrite, as its arguments are const > void*, size_t, size_t, FILE*. > >>> But it's nice that fixing the warning by adding a check >>> does catch this, and if fwrite ever fails, we now won't ignore it. >>> >>> Ok to push? >> >> I guess that as this is only a build-time issue then using the assert is ok. >> But the cynic in me won't be surprised if we find we get unexpected >> failures. That said, I'm not even sure if assertions are enabled during >> the build process ... >> > > They are at some point, that's what caused the previous failure :) > That also implies the code inside the assert is getting compiled. > >>> If so, I need a bug ID for it :) >> >> 6879689 (hope I did it right! not quite sure of the protocol for these :) ) >> > > Thanks! ?If I create one as an external user, I'm told to wait three > days. ?Last time, even that wasn't good enough and I had to get > Dalibor to push some buttons internally. > >> David Holmes >> >>>> David Holmes >>>> >>>> David Holmes - Sun Microsystems said the following on 09/08/09 10:32: >>>>> >>>>> David, >>>>> >>>>> David Schlosnagle said the following on 09/08/09 09:53: >>>>>> >>>>>> It seems like the warning and assert actually pointed out an existing >>>>>> bug -- the second and third arguments to fwrite seem to be swapped. >>>>>> The second arg should be the size (1 for char) and the third argument >>>>>> should is the number of items to write. >>>>> >>>>> I don't see how it makes a difference: size * 1 == 1 * size >>>>> >>>>> All fwrite will do, from what I've seen, is multiply the two to obtain >>>>> the >>>>> number of bytes to write. >>>>> >>>>> It may be that Andrew encountered this bug: [BZ #5998] >>>>> >>>>> >>>>> >>>>> http://sourceware.org/git/?p=glibc.git;a=commit;h=a7925a24fe104a2ab54fb8a6bdec1e5cf80a8db7 >>>>> >>>>> or maybe there really was an error writing the data out. >>>>> >>>>> Cheers, >>>>> David Holmes >>>>> >>>>>> The following should work: >>>>>> >>>>>> >>>>>> //---------------------------addSUNcopyright------------------------------- >>>>>> ?// output SUN copyright info >>>>>> ?void ArchDesc::addSunCopyright(char* legal, int size, FILE *fp) { >>>>>> - ?fwrite(legal, size, 1, fp); >>>>>> + ?size_t count = fwrite(legal, 1, size, fp); >>>>>> + ?assert(count == size, "copyright info truncated"); >>>>>> ?fprintf(fp,"\n"); >>>>>> ?fprintf(fp,"// Machine Generated File. ?Do Not Edit!\n"); >>>>>> ?fprintf(fp,"\n"); >>>>>> ?} >>>>>> >>>>>>> From : >>>>>> >>>>>> Synopsis >>>>>> ? #include >>>>>> ? size_t fwrite(const void *ptr, size_t size, size_t nitems, FILE >>>>>> *stream); >>>>>> >>>>>> Description >>>>>> ? The fwrite() function writes, from the array pointed to by ptr, up to >>>>>> ? nitems elements whose size is specified by size, to the stream >>>>>> pointed >>>>>> to >>>>>> ? by stream. For each object, size calls are made to the fputc(3C) >>>>>> function, >>>>>> ? taking the values (in order) from an array of unsigned char exactly >>>>>> ? overlaying the object. The file-position indicator for the stream (if >>>>>> ? defined) is advanced by the number of bytes successfully written. If >>>>>> an >>>>>> ? error occurs, the resulting value of the file-position indicator for >>>>>> the >>>>>> ? stream is unspecified. >>>>>> >>>>>> ? The st_ctime and st_mtime fields of the file will be marked for >>>>>> update >>>>>> ? between the successful execution of fwrite() and the next successful >>>>>> ? completion of a call to fflush(3C) or fclose(3C) on the same stream >>>>>> or >>>>>> a >>>>>> ? call to exit(2) or abort(3C). >>>>>> >>>>>> Return Values >>>>>> ? The fwrite() function returns the number of elements successfully >>>>>> written, >>>>>> ? which might be less than nitems if a write error is encountered. If >>>>>> size or >>>>>> ? nitems is 0, fwrite() returns 0 and the state of the stream remains >>>>>> ? unchanged. Otherwise, if a write error occurs, the error indicator >>>>>> for >>>>>> the >>>>>> ? stream is set and errno is set to indicate the error. >>>>>> >>>>>> Thanks, >>>>>> David Schlosnagle >>>>>> >>>>>> On Mon, Sep 7, 2009 at 6:40 PM, Andrew John Hughes >>>>>> wrote: >>>>>>> >>>>>>> 2009/9/6 Andrew John Hughes : >>>>>>>> >>>>>>>> 2009/9/5 David Holmes - Sun Microsystems : >>>>>>>>> >>>>>>>>> Christian Thalinger said the following on 09/05/09 18:59: >>>>>>>>>> >>>>>>>>>> Well, looking more closely it's actually a system header attribute >>>>>>>>>> that >>>>>>>>>> brings up that warning: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp:1034: >>>>>>>>>> error: ignoring return value of 'size_t fwrite(const void*, size_t, >>>>>>>>>> size_t, FILE*)', declared with attribute warn_unused_result >>>>>>>>>> >>>>>>>>>> And it seems there is no GCC switch to turn that warning off >>>>>>>>>> (except >>>>>>>>>> -O0). ?Maybe we should check for the written bytes to be the same >>>>>>>>>> as >>>>>>>>>> requested: >>>>>>>>>> >>>>>>>>>> ?assert(count == size, "copyright info truncated"); >>>>>>>>> >>>>>>>>> I recall this coming up in the past. gcc manual lists: >>>>>>>>> >>>>>>>>> -Wno-unused-result >>>>>>>>> >>>>>>>>> but that might be version specific. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>> It's a very recent addition: >>>>>>>> >>>>>>>> http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00474.html >>>>>>>> >>>>>>>> which means there is a period (which includes GCC 4.4) where the >>>>>>>> warning is produced but can't be disabled :( >>>>>>>> >>>>>>>> BTW, my current approach was influenced by >>>>>>>> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/2328d1d3f8cf where >>>>>>>> the same fix is applied to remove this warning. >>>>>>>> I have to say I personally prefer twisti's assert fix and can apply >>>>>>>> this if others are in agreement. >>>>>>>> -- >>>>>>>> Andrew :-) >>>>>>>> >>>>>>>> Free Java Software Engineer >>>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>>> >>>>>>>> Support Free Java! >>>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>>> http://www.gnu.org/software/classpath >>>>>>>> http://openjdk.java.net >>>>>>>> >>>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>>>>>> >>>>>>> This is interesting; that assertion fails: >>>>>>> >>>>>>> g++ -m64 -Xlinker -O1 ?-m64 -export-dynamic -o >>>>>>> ../generated/adfiles/adlc ../generated/adfiles/adlparse.o >>>>>>> ../generated/adfiles/archDesc.o ../generated/adfiles/arena.o >>>>>>> ../generated/adfiles/dfa.o ../generated/adfiles/dict2.o >>>>>>> ../generated/adfiles/filebuff.o ../generated/adfiles/forms.o >>>>>>> ../generated/adfiles/formsopt.o ../generated/adfiles/formssel.o >>>>>>> ../generated/adfiles/main.o ../generated/adfiles/adlc-opcodes.o >>>>>>> ../generated/adfiles/output_c.o ../generated/adfiles/output_h.o >>>>>>> ../generated/adfiles/adlc -DLINUX -D_GNU_SOURCE -DAMD64 -q -T -D_LP64 >>>>>>> ../generated/adfiles/linux_x86_64.ad ?\ >>>>>>> ?-c../generated/adfiles/mktmp11816/ad_x86_64.cpp >>>>>>> -h../generated/adfiles/mktmp11816/ad_x86_64.hpp >>>>>>> -a../generated/adfiles/mktmp11816/dfa_x86_64.cpp >>>>>>> -v../generated/adfiles/mktmp11816/adGlobals_x86_64.hpp \ >>>>>>> ? ? ? ? ?|| { rm -rf ../generated/adfiles/mktmp11816; exit 1; } >>>>>>> assert fails >>>>>>> >>>>>>> /mnt/builder/icedtea7/openjdk-ecj/hotspot/src/share/vm/adlc/archDesc.cpp >>>>>>> 1035: copyright info truncated >>>>>>> /bin/sh: line 2: 12016 Aborted >>>>>>> ../generated/adfiles/adlc -DLINUX -D_GNU_SOURCE -DAMD64 -q -T -D_LP64 >>>>>>> ../generated/adfiles/linux_x86_64.ad >>>>>>> -c../generated/adfiles/mktmp11816/ad_x86_64.cpp >>>>>>> -h../generated/adfiles/mktmp11816/ad_x86_64.hpp >>>>>>> -a../generated/adfiles/mktmp11816/dfa_x86_64.cpp >>>>>>> -v../generated/adfiles/mktmp11816/adGlobals_x86_64.hpp >>>>>>> make[7]: *** [refresh_adfiles] Error 1 >>>>>>> >>>>>>> -- >>>>>>> Andrew :-) >>>>>>> >>>>>>> Free Java Software Engineer >>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>> >>>>>>> Support Free Java! >>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>> http://www.gnu.org/software/classpath >>>>>>> http://openjdk.java.net >>>>>>> >>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>> >>> >>> >> > > > > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > From Christian.Thalinger at Sun.COM Tue Sep 8 01:16:11 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 08 Sep 2009 10:16:11 +0200 Subject: [PATCH FOR REVIEW]: Fix warning in src/share/vm/adlc/archDesc.cpp In-Reply-To: <9146341c0909071914j6e3ed33eof667dad6dce88085@mail.gmail.com> References: <17c6771e0909041518h20c4c809x27db9f5823896795@mail.gmail.com> <4AA24D4F.2010908@sun.com> <17c6771e0909060640w75fa3da3x8bcf0c387b1c151@mail.gmail.com> <17c6771e0909071540s5d86de45k538b4ddebdeb3fa9@mail.gmail.com> <9146341c0909071653u6ca39196w91989a43880d2107@mail.gmail.com> <4AA5A629.5020106@sun.com> <4AA5A74D.8050000@sun.com> <17c6771e0909071751o2b60a3d5ma02f88e2cb50ae73@mail.gmail.com> <4AA5AFA7.1000205@sun.com> <17c6771e0909071835h38256cc4g17f5df857cb2b921@mail.gmail.com> <9146341c0909071914j6e3ed33eof667dad6dce88085@mail.gmail.com> Message-ID: <4AA612CB.5060007@Sun.COM> David Schlosnagle wrote: > Is it worthwhile to change the method signature to better identify its > arguments? > > void ArchDesc::addSunCopyright(const char* legal, size_t size, FILE *fp) { > size_t count = fwrite(legal, sizeof(char), size, fp); > assert(count == size); > fprintf(fp,"\n"); > fprintf(fp,"// Machine Generated File. Do Not Edit!\n"); > fprintf(fp,"\n"); > } > > > Its a slippery slope to start checking the return values on those I/O > functions, and it doesn't look like anything else in that file is > checking them. I'm definitely not the right person to say whether the > assert is the proper error handling for this situation, but I'd assume > the user should know that the files weren't able to be written (most > likely due to some larger I/O problem) rather than fail silently. I'm not the right person too, as I'm too new to this. But checking a return value can't be too bad and if a build fails somewhere then we have a problem anyway. Additionally a truncated or bad generated file is likely to fail when we want to build it. -- Christian From gnu_andrew at member.fsf.org Tue Sep 8 06:50:18 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Sep 2009 14:50:18 +0100 Subject: [PATCH FOR REVIEW]: Fix warning in src/share/vm/adlc/archDesc.cpp In-Reply-To: <4AA612CB.5060007@Sun.COM> References: <17c6771e0909041518h20c4c809x27db9f5823896795@mail.gmail.com> <17c6771e0909071540s5d86de45k538b4ddebdeb3fa9@mail.gmail.com> <9146341c0909071653u6ca39196w91989a43880d2107@mail.gmail.com> <4AA5A629.5020106@sun.com> <4AA5A74D.8050000@sun.com> <17c6771e0909071751o2b60a3d5ma02f88e2cb50ae73@mail.gmail.com> <4AA5AFA7.1000205@sun.com> <17c6771e0909071835h38256cc4g17f5df857cb2b921@mail.gmail.com> <9146341c0909071914j6e3ed33eof667dad6dce88085@mail.gmail.com> <4AA612CB.5060007@Sun.COM> Message-ID: <17c6771e0909080650r3a1ce42md644be5c6e74a3d7@mail.gmail.com> 2009/9/8 Christian Thalinger : > David Schlosnagle wrote: >> Is it worthwhile to change the method signature to better identify its >> arguments? >> >> void ArchDesc::addSunCopyright(const char* legal, size_t size, FILE *fp) { >> ? ? size_t count = fwrite(legal, sizeof(char), size, fp); >> ? ? assert(count == size); >> ? ? fprintf(fp,"\n"); >> ? ? fprintf(fp,"// Machine Generated File. ?Do Not Edit!\n"); >> ? ? fprintf(fp,"\n"); >> } >> >> >> Its a slippery slope to start checking the return values on those I/O >> functions, and it doesn't look like anything else in that file is >> checking them. I'm definitely not the right person to say whether the >> assert is the proper error handling for this situation, but I'd assume >> the user should know that the files weren't able to be written (most >> likely due to some larger I/O problem) rather than fail silently. > > I'm not the right person too, as I'm too new to this. ?But checking a > return value can't be too bad and if a build fails somewhere then we > have a problem anyway. ?Additionally a truncated or bad generated file > is likely to fail when we want to build it. > > -- Christian > I pushed this, with a size_t cast to be on the safe side: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5fdbe2cdf565 Thanks to everyone who reviewed/commented on this, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From volker.simonis at gmail.com Fri Sep 11 05:59:58 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 11 Sep 2009 14:59:58 +0200 Subject: SA and disassemblers In-Reply-To: <147E5C84-EC8D-4628-82CE-33F815AE888D@sun.com> References: <147E5C84-EC8D-4628-82CE-33F815AE888D@sun.com> Message-ID: Hi Tom, I like the extension of the decode_instructions interface, especially because this is something we are already using anyway. We have extended the disassembler in the VM to decode instructions which had been dumped by the VM earlier when no disassembler library was available. We realized this with an 'AbstractDisassaembler' which in our case is the base class of 'Disassembler'. If the native disassembler can not be loaded, we automatically fall back to the abstract disassembler which prints a kind of hex dump, but with all the usual annotations. Later on, we can take such an output produced by the abstract disassembler (for example from an hs_err file) and decode it to real assembly code. Perhaps this is an extension you also want to consider? I could contribute some code if you'd like. Besides this I have some remarks/suggestions regarding hsdis: - I don't really think it is necessary for hsdis.c to export two functions: decode_instructions() and decode_instructions_virtual(). I think the more general one decode_instructions_virtual() would be enough together with a small change in disassembler.{cpp,hpp}: address decode_env::decode_instructions(address start, address end, address virtual_start /* = 0*/) { if (virtual_start == 0) virtual_start = start; This would unify the hsdis interface used by the VM and the SA and allow one to easily implement the decoding of "abstract disassembly" as described above. - in hsdis.c in hsdis_read_memory_func you use a C++ style comment which I think should be better changed into a C style comment and 'membar' should probably read 'mamaddr': ... + // convert the virtual address memaddr into an address within memory buffer + uintptr_t memaddr_p = ((uintptr_t) memaddr) - app_data->start_va + app_data->start; ... - The Readme file should contain the hint: "The binutils should be configured with the '--disable-nls' flag to disable Native Language Support, otherwise you might get an "undefined reference to `libintl_gettext'" if you try to load hsdis.so on systems which don't have NLS by default." - There's a typo in the README file of the hsdis plugin: line 70: 'hsdid-$LIBARCH.so' should read 'hsdis-$LIBARCH.so' - On IA64 and PPC, function pointers are pointers to function descriptors, so hsdis-demo.c should be changed accordingly: static const char* lookup(void* addr) { #if defined(__ia64) || defined(__powerpc__) /* On IA64 and PPC function pointers are pointers to function descriptors */ #define CHECK_NAME(fn) \ if (addr == *((void**) &fn)) return #fn; #else #define CHECK_NAME(fn) \ if (addr == (void*) &fn) return #fn; #endif ... void disassemble(void* from, void* to) { #if defined(__ia64) || defined(__powerpc__) /* On IA64 and PPC function pointers are pointers to function descriptors */ from = *((void**)from); to = *((void**)to); #endif - In the Makefile I need to link hsdis-demo against 'ld'. So I suggest adding (at least for Linux): LDFLAGS += -ldl - I don't understand why 'decode_instructions' in hsdis.c needs to print a newline after every instruction. I think it would be more consistent if this newline would be printed in the appropriate callback in the disassembler class. I would therefore suggest to delete the following lines from decode_instructions in hsdis.c: /* follow each complete insn by a nice newline */ /*(*printf_callback)(printf_stream, "\n");*/ - The previous change would also make it easier to use decode_instructions() to decode a single instruction. But it would be additionally necessary to change the line: while (p < end && !app_data.losing) { to: while (p <= end && !app_data.losing) { to make that possible. Additionally, "out of bound check" in hsdis_read_memory_func() will have to be removed, if we want to decode single instructions: if (memaddr_p + length > app_data->end) { /* read is out of bounds */ return EIO; } else { I don't think that this does any harm, but on the other side it will make the hsdis plugin more generally usable. Finally I would like to suggest moving the printing of nmethods and code blobs into the corresponding print methods of the CodeBlob and nmethod classes.This could be easily achieved with the new functionality which allows the decoding of a single assembler instruction. I don't see a reason why the disassembler class needs to know the internals of nmethod and CodeBlob. In my opinion it would be a cleaner design if the disassembler class would export a clear interface for decoding assembler instructions and leave all the rest to the class like nmethod or CodeBlob which use it. Again this would simplify the implementation of an "AbstractDisassembler" class as described above because the code which prints all the various annotations around the instructions would not have to be duplicated in the "AbstractDisassembler" class. Thank you and best regards, Volker On 8/27/09, Tom Rodriguez wrote: > One of the limitations of the current SA is that it doesn't have a > disassembler for amd64 which makes looking at 64 bit cores somewhat > challenging. Instead of trying to implement a full disassembler for x64 in > Java I think we should switch the SA to using hsdis-arch for the decoding. > It requires a minor extension to the decode_instructions interface so that > we can disassemble a buffer of code that's not physically located where the > code came from. I've got a working version of this that also fixes the > printing to match up better with what the JVM itself prints. I was planning > on blowing away the other disassemblers completely because they don't really > fit into the new model. I thought I'd float this before finishing it to see > if there are any concerns. The initial webrev is at > http://cr.openjdk.java.net/~never/sadis. This includes > building the SA with source 1.5 to allow use of printf which will probably > be pushed separately. > > tom > From gnu_andrew at member.fsf.org Fri Sep 11 09:07:40 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 11 Sep 2009 17:07:40 +0100 Subject: PING 3: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <19113.39846.175760.81942@sun.com> References: <17c6771e0909041021j10a046f0l5eec2e765bbe32e5@mail.gmail.com> <19105.21641.434524.306543@sun.com> <17c6771e0909041203x7b405e78pbc1586c3d26f5504@mail.gmail.com> <19105.63930.845263.728467@sun.com> <17c6771e0909060642y38631c09xf86f1121d938bb38@mail.gmail.com> <17c6771e0909070717k60d2be5cpce809698dc5aa0cb@mail.gmail.com> <19113.39846.175760.81942@sun.com> Message-ID: <17c6771e0909110907qd4b1b44wf43aa15fa8b729a5@mail.gmail.com> 2009/9/11 John Coomes : > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: >> > ... >> > Ok so this sounds like we need to go back to something similar to what >> > I started with, and patch each individual platform Makefile. ??Is that >> > correct? >> >> Here's a revised webrev: >> >> http://cr.openjdk.java.net/~andrew/ecj/03/webrev.05/hotspot.patch >> >> using rules.make for each platform instead of the top-level defs.make. >> It also includes the replacement of separate SA flags with just adding >> the same flags to SA and then following that with -source/target 1.4. >> Is this ok? > > Looks good so far. ?I'm trying some builds. > Ok, the patch you gave below looks ok to me. Are you testing with this patched version? Let me know if it goes ok, and if it does I'll push the patched version. >> >> Also, in prior email I suggested: >> >> >> >>> ..., if you update JAVAC_COMPILE to include BOOTSTRAP_JAVAC_FLAGS (or >> >>> whatever it is), and the SA makefile also includes -source/-target >> >>> options on the command-line, the latter will override the ones in >> >>> BOOTSTRAP_JAVAC_FLAGS (the SA command line may need to include both >> >>> -source and -target). ??At least try it, I think it'll be a simpler change. >> >> >> > >> > Ok, I must have missed this. ??It sounds a good idea and in the long >> > term I presume we want to get rid of the SA overrides anyway. > > That's closer, but not exactly what I was suggesting. ?Here's a patch > to apply on top of your patch. ?Basically, it includes > BOOTSTRAP_JAVAC_FLAGS in COMPILE.JAVAC (COMPILE_JAVAC on windows). > > -John > > > # HG changeset patch > # User jcoomes > # Date 1252627237 25200 > > diff --git a/make/linux/makefiles/jvmti.make b/make/linux/makefiles/jvmti.make > --- a/make/linux/makefiles/jvmti.make > +++ b/make/linux/makefiles/jvmti.make > @@ -70,10 +70,10 @@ > ?both = $(JvmtiGenClass) $(JvmtiSrcDir)/jvmti.xml $(JvmtiSrcDir)/jvmtiLib.xsl > > ?$(JvmtiGenClass): $(JvmtiGenSource) > - ? ? ? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -d $(JvmtiOutDir) $(JvmtiGenSource) > + ? ? ? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -d $(JvmtiOutDir) $(JvmtiGenSource) > > ?$(JvmtiEnvFillClass): $(JvmtiEnvFillSource) > - ? ? ? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) > + ? ? ? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) > > ?$(JvmtiOutDir)/jvmtiEnter.cpp: $(both) $(JvmtiSrcDir)/jvmtiEnter.xsl > ? ? ? ?@echo Generating $@ > diff --git a/make/linux/makefiles/rules.make b/make/linux/makefiles/rules.make > --- a/make/linux/makefiles/rules.make > +++ b/make/linux/makefiles/rules.make > @@ -122,6 +122,8 @@ > ?endif > ?endif > > +COMPILE.JAVAC += $(BOOTSTRAP_JAVAC_FLAGS) > + > ?SUM = /usr/bin/sum > > ?# 'gmake MAKE_VERBOSE=y' gives all the gory details. > diff --git a/make/linux/makefiles/sa.make b/make/linux/makefiles/sa.make > --- a/make/linux/makefiles/sa.make > +++ b/make/linux/makefiles/sa.make > @@ -74,8 +74,8 @@ > ? ? ? ? ?mkdir -p $(SA_CLASSDIR); ? ? ? ?\ > ? ? ? ?fi > > - ? ? ? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1) > - ? ? ? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2) > + ? ? ? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1) > + ? ? ? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2) > > ? ? ? ?$(QUIETLY) $(REMOTE) $(COMPILE.RMIC) ?-classpath $(SA_CLASSDIR) -d $(SA_CLASSDIR) sun.jvm.hotspot.debugger.remote.RemoteDebuggerServer > ? ? ? ?$(QUIETLY) echo "$(SA_BUILD_VERSION_PROP)" > $(SA_PROPERTIES) > diff --git a/make/linux/makefiles/top.make b/make/linux/makefiles/top.make > --- a/make/linux/makefiles/top.make > +++ b/make/linux/makefiles/top.make > @@ -114,7 +114,7 @@ > ?# make makeDeps: (and zap the cached db files to force a nonincremental run) > > ?$(GENERATED)/$(MakeDepsClass): $(MakeDepsSources) > - ? ? ? @$(REMOTE) $(COMPILE.JAVAC) -classpath $(GAMMADIR)/src/share/tools/MakeDeps $(BOOTSTRAP_JAVAC_FLAGS) -d $(GENERATED) $(MakeDepsSources) > + ? ? ? @$(REMOTE) $(COMPILE.JAVAC) -classpath $(GAMMADIR)/src/share/tools/MakeDeps -d $(GENERATED) $(MakeDepsSources) > ? ? ? ?@echo Removing $(Incremental_Lists) to force regeneration. > ? ? ? ?@rm -f $(Incremental_Lists) > ? ? ? ?@$(CDG) echo >$(Cached_plat) > diff --git a/make/solaris/makefiles/jvmti.make b/make/solaris/makefiles/jvmti.make > --- a/make/solaris/makefiles/jvmti.make > +++ b/make/solaris/makefiles/jvmti.make > @@ -69,10 +69,10 @@ > ?both = $(JvmtiGenClass) $(JvmtiSrcDir)/jvmti.xml $(JvmtiSrcDir)/jvmtiLib.xsl > > ?$(JvmtiGenClass): $(JvmtiGenSource) > - ? ? ? $(QUIETLY) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -d $(JvmtiOutDir) $(JvmtiGenSource) > + ? ? ? $(QUIETLY) $(COMPILE.JAVAC) -d $(JvmtiOutDir) $(JvmtiGenSource) > > ?$(JvmtiEnvFillClass): $(JvmtiEnvFillSource) > - ? ? ? $(QUIETLY) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) > + ? ? ? $(QUIETLY) $(COMPILE.JAVAC) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) > > ?$(JvmtiOutDir)/jvmtiEnter.cpp: $(both) $(JvmtiSrcDir)/jvmtiEnter.xsl > ? ? ? ?@echo Generating $@ > diff --git a/make/solaris/makefiles/rules.make b/make/solaris/makefiles/rules.make > --- a/make/solaris/makefiles/rules.make > +++ b/make/solaris/makefiles/rules.make > @@ -122,6 +122,8 @@ > ?endif > ?endif > > +COMPILE.JAVAC += $(BOOTSTRAP_JAVAC_FLAGS) > + > ?SUM = /usr/bin/sum > > ?# 'gmake MAKE_VERBOSE=y' gives all the gory details. > diff --git a/make/solaris/makefiles/sa.make b/make/solaris/makefiles/sa.make > --- a/make/solaris/makefiles/sa.make > +++ b/make/solaris/makefiles/sa.make > @@ -67,9 +67,9 @@ > ? ? ? ?$(QUIETLY) if [ ! -d $(SA_CLASSDIR) ] ; then \ > ? ? ? ? ?mkdir -p $(SA_CLASSDIR); ? ? ? ?\ > ? ? ? ?fi > - ? ? ? $(QUIETLY) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1) > - ? ? ? $(QUIETLY) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2) > - > + ? ? ? $(QUIETLY) $(COMPILE.JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1) > + ? ? ? $(QUIETLY) $(COMPILE.JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2) > + > ? ? ? ?$(QUIETLY) $(COMPILE.RMIC) ?-classpath $(SA_CLASSDIR) -d $(SA_CLASSDIR) sun.jvm.hotspot.debugger.remote.RemoteDebuggerServer > ? ? ? ?$(QUIETLY) echo "$(SA_BUILD_VERSION_PROP)" > $(SA_PROPERTIES) > ? ? ? ?$(QUIETLY) rm -f $(SA_CLASSDIR)/sun/jvm/hotspot/utilities/soql/sa.js > diff --git a/make/solaris/makefiles/top.make b/make/solaris/makefiles/top.make > --- a/make/solaris/makefiles/top.make > +++ b/make/solaris/makefiles/top.make > @@ -112,7 +112,7 @@ > ?# make makeDeps: (and zap the cached db files to force a nonincremental run) > > ?$(GENERATED)/$(MakeDepsClass): $(MakeDepsSources) > - ? ? ? @$(COMPILE.JAVAC) -classpath $(GAMMADIR)/src/share/tools/MakeDeps $(BOOTSTRAP_JAVAC_FLAGS) -d $(GENERATED) $(MakeDepsSources) > + ? ? ? @$(COMPILE.JAVAC) -classpath $(GAMMADIR)/src/share/tools/MakeDeps -d $(GENERATED) $(MakeDepsSources) > ? ? ? ?@echo Removing $(Incremental_Lists) to force regeneration. > ? ? ? ?@rm -f $(Incremental_Lists) > ? ? ? ?@$(CDG) echo >$(Cached_plat) > diff --git a/make/windows/makefiles/generated.make b/make/windows/makefiles/generated.make > --- a/make/windows/makefiles/generated.make > +++ b/make/windows/makefiles/generated.make > @@ -91,7 +91,7 @@ > ?classes/MakeDeps.class: $(MakeDepsSources) > ? ? ? ?if exist classes rmdir /s /q classes > ? ? ? ?mkdir classes > - ? ? ? $(COMPILE_JAVAC) -classpath $(WorkSpace)\src\share\tools\MakeDeps $(BOOTSTRAP_JAVAC_FLAGS) -d classes $(MakeDepsSources) > + ? ? ? $(COMPILE_JAVAC) -classpath $(WorkSpace)\src\share\tools\MakeDeps -d classes $(MakeDepsSources) > > ?!if ("$(Variant)" == "compiler2") || ("$(Variant)" == "tiered") > > diff --git a/make/windows/makefiles/jvmti.make b/make/windows/makefiles/jvmti.make > --- a/make/windows/makefiles/jvmti.make > +++ b/make/windows/makefiles/jvmti.make > @@ -68,10 +68,10 @@ > ? ? ? ? @if not exist $(JvmtiOutDir) mkdir $(JvmtiOutDir) > > ?$(JvmtiGenClass): $(JvmtiGenSource) > - ? ? ? $(COMPILE_JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -d $(JvmtiOutDir) $(JvmtiGenSource) > + ? ? ? $(COMPILE_JAVAC) -d $(JvmtiOutDir) $(JvmtiGenSource) > > ?$(JvmtiEnvFillClass): $(JvmtiEnvFillSource) > - ? ? ? @$(COMPILE_JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) > + ? ? ? @$(COMPILE_JAVAC) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) > > ?$(JvmtiOutDir)/jvmtiEnter.cpp: $(both) $(JvmtiSrcDir)/jvmtiEnter.xsl > ? ? ? ?@echo Generating $@ > diff --git a/make/windows/makefiles/rules.make b/make/windows/makefiles/rules.make > --- a/make/windows/makefiles/rules.make > +++ b/make/windows/makefiles/rules.make > @@ -29,7 +29,7 @@ > ?RUN_JAVAP=$(BootStrapDir)\bin\javap > ?RUN_JAVAH=$(BootStrapDir)\bin\javah > ?RUN_JAR=$(BootStrapDir)\bin\jar > -COMPILE_JAVAC=$(BootStrapDir)\bin\javac > +COMPILE_JAVAC=$(BootStrapDir)\bin\javac $(BOOTSTRAP_JAVAC_FLAGS) > ?COMPILE_RMIC=$(BootStrapDir)\bin\rmic > ?BOOT_JAVA_HOME=$(BootStrapDir) > ?!else > @@ -37,7 +37,7 @@ > ?RUN_JAVAP=javap > ?RUN_JAVAH=javah > ?RUN_JAR=jar > -COMPILE_JAVAC=javac > +COMPILE_JAVAC=javac $(BOOTSTRAP_JAVAC_FLAGS) > ?COMPILE_RMIC=rmic > ?BOOT_JAVA_HOME= > ?!endif > diff --git a/make/windows/makefiles/sa.make b/make/windows/makefiles/sa.make > --- a/make/windows/makefiles/sa.make > +++ b/make/windows/makefiles/sa.make > @@ -55,9 +55,9 @@ > ?$(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\) > ? ? ? ?@if not exist $(SA_CLASSDIR) mkdir $(SA_CLASSDIR) > ? ? ? ?@echo ...Building sa-jdi.jar > - ? ? ? @echo ...$(COMPILE_JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -d $(SA_CLASSDIR) .... > - ? ? ? @$(COMPILE_JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\) > - ? ? ? @$(COMPILE_JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\) > + ? ? ? @echo ...$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -d $(SA_CLASSDIR) .... > + ? ? ? @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\) > + ? ? ? @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\) > ? ? ? ?$(COMPILE_RMIC) -classpath $(SA_CLASSDIR) -d $(SA_CLASSDIR) sun.jvm.hotspot.debugger.remote.RemoteDebuggerServer > ? ? ? ?$(QUIETLY) echo $(SA_BUILD_VERSION_PROP)> $(SA_PROPERTIES) > ? ? ? ?$(QUIETLY) rm -f $(SA_CLASSDIR)/sun/jvm/hotspot/utilities/soql/sa.js > diff --git a/make/windows/projectfiles/common/Makefile b/make/windows/projectfiles/common/Makefile > --- a/make/windows/projectfiles/common/Makefile > +++ b/make/windows/projectfiles/common/Makefile > @@ -179,6 +179,6 @@ > ?$(HOTSPOTBUILDSPACE)/classes/MakeDeps.class: $(MakeDepsSources) > ? ? ? ?@if exist $(HOTSPOTBUILDSPACE)\classes rmdir /s /q $(HOTSPOTBUILDSPACE)\classes > ? ? ? ?@mkdir $(HOTSPOTBUILDSPACE)\classes > - ? ? ? @$(COMPILE_JAVAC) -classpath $(HOTSPOTWORKSPACE)\src\share\tools\MakeDeps $(BOOTSTRAP_JAVAC_FLAGS) -d $(HOTSPOTBUILDSPACE)/classes $(MakeDepsSources) > + ? ? ? @$(COMPILE_JAVAC) -classpath $(HOTSPOTWORKSPACE)\src\share\tools\MakeDeps -d $(HOTSPOTBUILDSPACE)/classes $(MakeDepsSources) > > ?FORCE: > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From mr at sun.com Fri Sep 11 09:22:52 2009 From: mr at sun.com (Mark Reinhold) Date: Fri, 11 Sep 2009 09:22:52 -0700 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: joe.darcy@sun.com; Tue, 25 Aug 2009 21:36:27 PDT; <4A94BBCB.9020206@sun.com> Message-ID: <20090911162252.501B95B8@eggemoggin.niobe.net> I've updated the jcheck extension to allow the unique-bugid restriction to be disabled, and I've disabled that check in the jdk6 forest. Joe: For the benefit of those using jcheck in their working repos I suggest you update the .jcheck/conf file in each repo to read: project=jdk6 whitespace=lax comments=lax bugids=dup As for the extension itself, I'm working to get it published externally, hopefully in the next week or two. - Mark From gnu_andrew at member.fsf.org Fri Sep 11 10:06:06 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 11 Sep 2009 18:06:06 +0100 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <20090911162252.501B95B8@eggemoggin.niobe.net> References: <4A94BBCB.9020206@sun.com> <20090911162252.501B95B8@eggemoggin.niobe.net> Message-ID: <17c6771e0909111006p8f4eb43wc006678ed55af3f1@mail.gmail.com> 2009/9/11 Mark Reinhold : > I've updated the jcheck extension to allow the unique-bugid > restriction to be disabled, and I've disabled that check in > the jdk6 forest. > > Joe: For the benefit of those using jcheck in their working > repos I suggest you update the .jcheck/conf file in each repo > to read: > > ? ?project=jdk6 > ? ?whitespace=lax > ? ?comments=lax > ? ?bugids=dup > > As for the extension itself, I'm working to get it published > externally, hopefully in the next week or two. > > - Mark > I don't yet see any incoming changes for jdk6, but I'll check again on Sunday and try to push the HotSpot merge. I'm away next week and don't really want to leave it pending much longer. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Kelly.Ohair at Sun.COM Fri Sep 11 10:26:31 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 11 Sep 2009 10:26:31 -0700 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <20090911162252.501B95B8@eggemoggin.niobe.net> References: <20090911162252.501B95B8@eggemoggin.niobe.net> Message-ID: <4AAA8847.4060409@sun.com> I think a bugid will be needed to push in the changesets that change the .jcheck/conf files in jdk6, shall I file one? One bugid should cover all of the jdk6 repositories. And I could push the changes in if need be, just say the word. -kto Mark Reinhold wrote: > I've updated the jcheck extension to allow the unique-bugid > restriction to be disabled, and I've disabled that check in > the jdk6 forest. > > Joe: For the benefit of those using jcheck in their working > repos I suggest you update the .jcheck/conf file in each repo > to read: > > project=jdk6 > whitespace=lax > comments=lax > bugids=dup > > As for the extension itself, I'm working to get it published > externally, hopefully in the next week or two. > > - Mark From Joe.Darcy at Sun.COM Fri Sep 11 10:30:16 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 11 Sep 2009 10:30:16 -0700 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <4AAA8847.4060409@sun.com> References: <20090911162252.501B95B8@eggemoggin.niobe.net> <4AAA8847.4060409@sun.com> Message-ID: <4AAA8928.7030204@sun.com> Kelly, Yes, please file a bug and push the changes; I approve these changes going back. -Joe Kelly O'Hair wrote: > I think a bugid will be needed to push in the changesets that > change the .jcheck/conf files in jdk6, shall I file one? > One bugid should cover all of the jdk6 repositories. > > And I could push the changes in if need be, just say the word. > > -kto > > Mark Reinhold wrote: >> I've updated the jcheck extension to allow the unique-bugid >> restriction to be disabled, and I've disabled that check in >> the jdk6 forest. >> >> Joe: For the benefit of those using jcheck in their working >> repos I suggest you update the .jcheck/conf file in each repo >> to read: >> >> project=jdk6 >> whitespace=lax >> comments=lax >> bugids=dup >> >> As for the extension itself, I'm working to get it published >> externally, hopefully in the next week or two. >> >> - Mark From Kelly.Ohair at Sun.COM Fri Sep 11 11:04:22 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 11 Sep 2009 11:04:22 -0700 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <4AAA8928.7030204@sun.com> References: <20090911162252.501B95B8@eggemoggin.niobe.net> <4AAA8847.4060409@sun.com> <4AAA8928.7030204@sun.com> Message-ID: <4AAA9126.2030308@sun.com> Pushing now... or should I say ppppppuuuuuuusssssssshhhhhhhiiiiiinnnnnggggggg nnnnnnnnnooooooooooowwwwwwwwwww It's very slow. :^( Hopefully in the next 30mins... -kto Joseph D. Darcy wrote: > Kelly, > > Yes, please file a bug and push the changes; I approve these changes > going back. > > -Joe > > Kelly O'Hair wrote: >> I think a bugid will be needed to push in the changesets that >> change the .jcheck/conf files in jdk6, shall I file one? >> One bugid should cover all of the jdk6 repositories. >> >> And I could push the changes in if need be, just say the word. >> >> -kto >> >> Mark Reinhold wrote: >>> I've updated the jcheck extension to allow the unique-bugid >>> restriction to be disabled, and I've disabled that check in >>> the jdk6 forest. >>> >>> Joe: For the benefit of those using jcheck in their working >>> repos I suggest you update the .jcheck/conf file in each repo >>> to read: >>> >>> project=jdk6 >>> whitespace=lax >>> comments=lax >>> bugids=dup >>> >>> As for the extension itself, I'm working to get it published >>> externally, hopefully in the next week or two. >>> >>> - Mark > From John.Coomes at sun.com Fri Sep 11 11:42:01 2009 From: John.Coomes at sun.com (John Coomes) Date: Fri, 11 Sep 2009 11:42:01 -0700 Subject: PING 3: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <17c6771e0909110907qd4b1b44wf43aa15fa8b729a5@mail.gmail.com> References: <17c6771e0909041021j10a046f0l5eec2e765bbe32e5@mail.gmail.com> <19105.21641.434524.306543@sun.com> <17c6771e0909041203x7b405e78pbc1586c3d26f5504@mail.gmail.com> <19105.63930.845263.728467@sun.com> <17c6771e0909060642y38631c09xf86f1121d938bb38@mail.gmail.com> <17c6771e0909070717k60d2be5cpce809698dc5aa0cb@mail.gmail.com> <19113.39846.175760.81942@sun.com> <17c6771e0909110907qd4b1b44wf43aa15fa8b729a5@mail.gmail.com> Message-ID: <19114.39417.509560.251572@sun.com> Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: > 2009/9/11 John Coomes : > > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: > >> > ... > >> > Ok so this sounds like we need to go back to something similar to what > >> > I started with, and patch each individual platform Makefile. ????Is that > >> > correct? > >> > >> Here's a revised webrev: > >> > >> http://cr.openjdk.java.net/~andrew/ecj/03/webrev.05/hotspot.patch > >> > >> using rules.make for each platform instead of the top-level defs.make. > >> It also includes the replacement of separate SA flags with just adding > >> the same flags to SA and then following that with -source/target 1.4. > >> Is this ok? > > > > Looks good so far. ??I'm trying some builds. > > > > Ok, the patch you gave below looks ok to me. Are you testing with > this patched version? > Let me know if it goes ok, and if it does I'll push the patched version. I tested both on solaris & linux (all good). I'll also try windows shortly. Note that we (hotspot) use an auto-build system called jprt for all changes; it builds & tests on all platforms and does the push if everything is clean. If you create a changeset that jcheck will accept I'll submit it for you to jprt. Include me as a reviewer (jcoomes). You can publish the repo or generate a patch w/hg headers using 'hg export'. -John > >> >> Also, in prior email I suggested: > >> >> > >> >>> ..., if you update JAVAC_COMPILE to include BOOTSTRAP_JAVAC_FLAGS (or > >> >>> whatever it is), and the SA makefile also includes -source/-target > >> >>> options on the command-line, the latter will override the ones in > >> >>> BOOTSTRAP_JAVAC_FLAGS (the SA command line may need to include both > >> >>> -source and -target). ????At least try it, I think it'll be a simpler change. > >> >> > >> > > >> > Ok, I must have missed this. ????It sounds a good idea and in the long > >> > term I presume we want to get rid of the SA overrides anyway. > > > > That's closer, but not exactly what I was suggesting. ??Here's a patch > > to apply on top of your patch. ??Basically, it includes > > BOOTSTRAP_JAVAC_FLAGS in COMPILE.JAVAC (COMPILE_JAVAC on windows). > > > > -John > > > > > > # HG changeset patch > > # User jcoomes > > # Date 1252627237 25200 > > > > diff --git a/make/linux/makefiles/jvmti.make b/make/linux/makefiles/jvmti.make > > --- a/make/linux/makefiles/jvmti.make > > +++ b/make/linux/makefiles/jvmti.make > > @@ -70,10 +70,10 @@ > > ??both = $(JvmtiGenClass) $(JvmtiSrcDir)/jvmti.xml $(JvmtiSrcDir)/jvmtiLib.xsl > > > > ??$(JvmtiGenClass): $(JvmtiGenSource) > > - ?? ?? ?? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -d $(JvmtiOutDir) $(JvmtiGenSource) > > + ?? ?? ?? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -d $(JvmtiOutDir) $(JvmtiGenSource) > > > > ??$(JvmtiEnvFillClass): $(JvmtiEnvFillSource) > > - ?? ?? ?? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) > > + ?? ?? ?? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) > > > > ??$(JvmtiOutDir)/jvmtiEnter.cpp: $(both) $(JvmtiSrcDir)/jvmtiEnter.xsl > > ?? ?? ?? ??@echo Generating $@ > > diff --git a/make/linux/makefiles/rules.make b/make/linux/makefiles/rules.make > > --- a/make/linux/makefiles/rules.make > > +++ b/make/linux/makefiles/rules.make > > @@ -122,6 +122,8 @@ > > ??endif > > ??endif > > > > +COMPILE.JAVAC += $(BOOTSTRAP_JAVAC_FLAGS) > > + > > ??SUM = /usr/bin/sum > > > > ??# 'gmake MAKE_VERBOSE=y' gives all the gory details. > > diff --git a/make/linux/makefiles/sa.make b/make/linux/makefiles/sa.make > > --- a/make/linux/makefiles/sa.make > > +++ b/make/linux/makefiles/sa.make > > @@ -74,8 +74,8 @@ > > ?? ?? ?? ?? ??mkdir -p $(SA_CLASSDIR); ?? ?? ?? ??\ > > ?? ?? ?? ??fi > > > > - ?? ?? ?? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1) > > - ?? ?? ?? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2) > > + ?? ?? ?? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1) > > + ?? ?? ?? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2) > > > > ?? ?? ?? ??$(QUIETLY) $(REMOTE) $(COMPILE.RMIC) ??-classpath $(SA_CLASSDIR) -d $(SA_CLASSDIR) sun.jvm.hotspot.debugger.remote.RemoteDebuggerServer > > ?? ?? ?? ??$(QUIETLY) echo "$(SA_BUILD_VERSION_PROP)" > $(SA_PROPERTIES) > > diff --git a/make/linux/makefiles/top.make b/make/linux/makefiles/top.make > > --- a/make/linux/makefiles/top.make > > +++ b/make/linux/makefiles/top.make > > @@ -114,7 +114,7 @@ > > ??# make makeDeps: (and zap the cached db files to force a nonincremental run) > > > > ??$(GENERATED)/$(MakeDepsClass): $(MakeDepsSources) > > - ?? ?? ?? @$(REMOTE) $(COMPILE.JAVAC) -classpath $(GAMMADIR)/src/share/tools/MakeDeps $(BOOTSTRAP_JAVAC_FLAGS) -d $(GENERATED) $(MakeDepsSources) > > + ?? ?? ?? @$(REMOTE) $(COMPILE.JAVAC) -classpath $(GAMMADIR)/src/share/tools/MakeDeps -d $(GENERATED) $(MakeDepsSources) > > ?? ?? ?? ??@echo Removing $(Incremental_Lists) to force regeneration. > > ?? ?? ?? ??@rm -f $(Incremental_Lists) > > ?? ?? ?? ??@$(CDG) echo >$(Cached_plat) > > diff --git a/make/solaris/makefiles/jvmti.make b/make/solaris/makefiles/jvmti.make > > --- a/make/solaris/makefiles/jvmti.make > > +++ b/make/solaris/makefiles/jvmti.make > > @@ -69,10 +69,10 @@ > > ??both = $(JvmtiGenClass) $(JvmtiSrcDir)/jvmti.xml $(JvmtiSrcDir)/jvmtiLib.xsl > > > > ??$(JvmtiGenClass): $(JvmtiGenSource) > > - ?? ?? ?? $(QUIETLY) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -d $(JvmtiOutDir) $(JvmtiGenSource) > > + ?? ?? ?? $(QUIETLY) $(COMPILE.JAVAC) -d $(JvmtiOutDir) $(JvmtiGenSource) > > > > ??$(JvmtiEnvFillClass): $(JvmtiEnvFillSource) > > - ?? ?? ?? $(QUIETLY) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) > > + ?? ?? ?? $(QUIETLY) $(COMPILE.JAVAC) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) > > > > ??$(JvmtiOutDir)/jvmtiEnter.cpp: $(both) $(JvmtiSrcDir)/jvmtiEnter.xsl > > ?? ?? ?? ??@echo Generating $@ > > diff --git a/make/solaris/makefiles/rules.make b/make/solaris/makefiles/rules.make > > --- a/make/solaris/makefiles/rules.make > > +++ b/make/solaris/makefiles/rules.make > > @@ -122,6 +122,8 @@ > > ??endif > > ??endif > > > > +COMPILE.JAVAC += $(BOOTSTRAP_JAVAC_FLAGS) > > + > > ??SUM = /usr/bin/sum > > > > ??# 'gmake MAKE_VERBOSE=y' gives all the gory details. > > diff --git a/make/solaris/makefiles/sa.make b/make/solaris/makefiles/sa.make > > --- a/make/solaris/makefiles/sa.make > > +++ b/make/solaris/makefiles/sa.make > > @@ -67,9 +67,9 @@ > > ?? ?? ?? ??$(QUIETLY) if [ ! -d $(SA_CLASSDIR) ] ; then \ > > ?? ?? ?? ?? ??mkdir -p $(SA_CLASSDIR); ?? ?? ?? ??\ > > ?? ?? ?? ??fi > > - ?? ?? ?? $(QUIETLY) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1) > > - ?? ?? ?? $(QUIETLY) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2) > > - > > + ?? ?? ?? $(QUIETLY) $(COMPILE.JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1) > > + ?? ?? ?? $(QUIETLY) $(COMPILE.JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2) > > + > > ?? ?? ?? ??$(QUIETLY) $(COMPILE.RMIC) ??-classpath $(SA_CLASSDIR) -d $(SA_CLASSDIR) sun.jvm.hotspot.debugger.remote.RemoteDebuggerServer > > ?? ?? ?? ??$(QUIETLY) echo "$(SA_BUILD_VERSION_PROP)" > $(SA_PROPERTIES) > > ?? ?? ?? ??$(QUIETLY) rm -f $(SA_CLASSDIR)/sun/jvm/hotspot/utilities/soql/sa.js > > diff --git a/make/solaris/makefiles/top.make b/make/solaris/makefiles/top.make > > --- a/make/solaris/makefiles/top.make > > +++ b/make/solaris/makefiles/top.make > > @@ -112,7 +112,7 @@ > > ??# make makeDeps: (and zap the cached db files to force a nonincremental run) > > > > ??$(GENERATED)/$(MakeDepsClass): $(MakeDepsSources) > > - ?? ?? ?? @$(COMPILE.JAVAC) -classpath $(GAMMADIR)/src/share/tools/MakeDeps $(BOOTSTRAP_JAVAC_FLAGS) -d $(GENERATED) $(MakeDepsSources) > > + ?? ?? ?? @$(COMPILE.JAVAC) -classpath $(GAMMADIR)/src/share/tools/MakeDeps -d $(GENERATED) $(MakeDepsSources) > > ?? ?? ?? ??@echo Removing $(Incremental_Lists) to force regeneration. > > ?? ?? ?? ??@rm -f $(Incremental_Lists) > > ?? ?? ?? ??@$(CDG) echo >$(Cached_plat) > > diff --git a/make/windows/makefiles/generated.make b/make/windows/makefiles/generated.make > > --- a/make/windows/makefiles/generated.make > > +++ b/make/windows/makefiles/generated.make > > @@ -91,7 +91,7 @@ > > ??classes/MakeDeps.class: $(MakeDepsSources) > > ?? ?? ?? ??if exist classes rmdir /s /q classes > > ?? ?? ?? ??mkdir classes > > - ?? ?? ?? $(COMPILE_JAVAC) -classpath $(WorkSpace)\src\share\tools\MakeDeps $(BOOTSTRAP_JAVAC_FLAGS) -d classes $(MakeDepsSources) > > + ?? ?? ?? $(COMPILE_JAVAC) -classpath $(WorkSpace)\src\share\tools\MakeDeps -d classes $(MakeDepsSources) > > > > ??!if ("$(Variant)" == "compiler2") || ("$(Variant)" == "tiered") > > > > diff --git a/make/windows/makefiles/jvmti.make b/make/windows/makefiles/jvmti.make > > --- a/make/windows/makefiles/jvmti.make > > +++ b/make/windows/makefiles/jvmti.make > > @@ -68,10 +68,10 @@ > > ?? ?? ?? ?? @if not exist $(JvmtiOutDir) mkdir $(JvmtiOutDir) > > > > ??$(JvmtiGenClass): $(JvmtiGenSource) > > - ?? ?? ?? $(COMPILE_JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -d $(JvmtiOutDir) $(JvmtiGenSource) > > + ?? ?? ?? $(COMPILE_JAVAC) -d $(JvmtiOutDir) $(JvmtiGenSource) > > > > ??$(JvmtiEnvFillClass): $(JvmtiEnvFillSource) > > - ?? ?? ?? @$(COMPILE_JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) > > + ?? ?? ?? @$(COMPILE_JAVAC) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) > > > > ??$(JvmtiOutDir)/jvmtiEnter.cpp: $(both) $(JvmtiSrcDir)/jvmtiEnter.xsl > > ?? ?? ?? ??@echo Generating $@ > > diff --git a/make/windows/makefiles/rules.make b/make/windows/makefiles/rules.make > > --- a/make/windows/makefiles/rules.make > > +++ b/make/windows/makefiles/rules.make > > @@ -29,7 +29,7 @@ > > ??RUN_JAVAP=$(BootStrapDir)\bin\javap > > ??RUN_JAVAH=$(BootStrapDir)\bin\javah > > ??RUN_JAR=$(BootStrapDir)\bin\jar > > -COMPILE_JAVAC=$(BootStrapDir)\bin\javac > > +COMPILE_JAVAC=$(BootStrapDir)\bin\javac $(BOOTSTRAP_JAVAC_FLAGS) > > ??COMPILE_RMIC=$(BootStrapDir)\bin\rmic > > ??BOOT_JAVA_HOME=$(BootStrapDir) > > ??!else > > @@ -37,7 +37,7 @@ > > ??RUN_JAVAP=javap > > ??RUN_JAVAH=javah > > ??RUN_JAR=jar > > -COMPILE_JAVAC=javac > > +COMPILE_JAVAC=javac $(BOOTSTRAP_JAVAC_FLAGS) > > ??COMPILE_RMIC=rmic > > ??BOOT_JAVA_HOME= > > ??!endif > > diff --git a/make/windows/makefiles/sa.make b/make/windows/makefiles/sa.make > > --- a/make/windows/makefiles/sa.make > > +++ b/make/windows/makefiles/sa.make > > @@ -55,9 +55,9 @@ > > ??$(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\) > > ?? ?? ?? ??@if not exist $(SA_CLASSDIR) mkdir $(SA_CLASSDIR) > > ?? ?? ?? ??@echo ...Building sa-jdi.jar > > - ?? ?? ?? @echo ...$(COMPILE_JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -d $(SA_CLASSDIR) .... > > - ?? ?? ?? @$(COMPILE_JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\) > > - ?? ?? ?? @$(COMPILE_JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\) > > + ?? ?? ?? @echo ...$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -d $(SA_CLASSDIR) .... > > + ?? ?? ?? @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\) > > + ?? ?? ?? @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\) > > ?? ?? ?? ??$(COMPILE_RMIC) -classpath $(SA_CLASSDIR) -d $(SA_CLASSDIR) sun.jvm.hotspot.debugger.remote.RemoteDebuggerServer > > ?? ?? ?? ??$(QUIETLY) echo $(SA_BUILD_VERSION_PROP)> $(SA_PROPERTIES) > > ?? ?? ?? ??$(QUIETLY) rm -f $(SA_CLASSDIR)/sun/jvm/hotspot/utilities/soql/sa.js > > diff --git a/make/windows/projectfiles/common/Makefile b/make/windows/projectfiles/common/Makefile > > --- a/make/windows/projectfiles/common/Makefile > > +++ b/make/windows/projectfiles/common/Makefile > > @@ -179,6 +179,6 @@ > > ??$(HOTSPOTBUILDSPACE)/classes/MakeDeps.class: $(MakeDepsSources) > > ?? ?? ?? ??@if exist $(HOTSPOTBUILDSPACE)\classes rmdir /s /q $(HOTSPOTBUILDSPACE)\classes > > ?? ?? ?? ??@mkdir $(HOTSPOTBUILDSPACE)\classes > > - ?? ?? ?? @$(COMPILE_JAVAC) -classpath $(HOTSPOTWORKSPACE)\src\share\tools\MakeDeps $(BOOTSTRAP_JAVAC_FLAGS) -d $(HOTSPOTBUILDSPACE)/classes $(MakeDepsSources) > > + ?? ?? ?? @$(COMPILE_JAVAC) -classpath $(HOTSPOTWORKSPACE)\src\share\tools\MakeDeps -d $(HOTSPOTBUILDSPACE)/classes $(MakeDepsSources) > > > > ??FORCE: > > > > > > > > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Fri Sep 11 11:43:47 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 11 Sep 2009 11:43:47 -0700 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <4AAA9126.2030308@sun.com> References: <20090911162252.501B95B8@eggemoggin.niobe.net> <4AAA8847.4060409@sun.com> <4AAA8928.7030204@sun.com> <4AAA9126.2030308@sun.com> Message-ID: <4AAA9A63.2010200@sun.com> Thanks Kelly, -Joe Kelly O'Hair wrote: > Pushing now... or should I say > ppppppuuuuuuusssssssshhhhhhhiiiiiinnnnnggggggg > nnnnnnnnnooooooooooowwwwwwwwwww > > It's very slow. :^( > > Hopefully in the next 30mins... > > -kto > > Joseph D. Darcy wrote: >> Kelly, >> >> Yes, please file a bug and push the changes; I approve these changes >> going back. >> >> -Joe >> >> Kelly O'Hair wrote: >>> I think a bugid will be needed to push in the changesets that >>> change the .jcheck/conf files in jdk6, shall I file one? >>> One bugid should cover all of the jdk6 repositories. >>> >>> And I could push the changes in if need be, just say the word. >>> >>> -kto >>> >>> Mark Reinhold wrote: >>>> I've updated the jcheck extension to allow the unique-bugid >>>> restriction to be disabled, and I've disabled that check in >>>> the jdk6 forest. >>>> >>>> Joe: For the benefit of those using jcheck in their working >>>> repos I suggest you update the .jcheck/conf file in each repo >>>> to read: >>>> >>>> project=jdk6 >>>> whitespace=lax >>>> comments=lax >>>> bugids=dup >>>> >>>> As for the extension itself, I'm working to get it published >>>> externally, hopefully in the next week or two. >>>> >>>> - Mark >> From andrey.petrusenko at sun.com Fri Sep 11 12:23:25 2009 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Fri, 11 Sep 2009 19:23:25 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20090911192354.E1D8412008@hg.openjdk.java.net> Changeset: b1f5ced5da21 Author: jcoomes Date: 2009-09-03 19:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b1f5ced5da21 6879076: disable jprt sync after builds are done Reviewed-by: kamg, dholmes ! make/jprt.properties Changeset: 68ef3fdcdb76 Author: ysr Date: 2009-09-10 16:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/68ef3fdcdb76 6872136: CMS: confusing message may be printed when a collector is switched off implicitly Summary: Fix CDS/CMS option overrides related to iCMS option CMSIncrementalMode; explicate overrides to error stream. Reviewed-by: coleenp ! src/share/vm/runtime/arguments.cpp From Kelly.Ohair at Sun.COM Fri Sep 11 12:35:30 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 11 Sep 2009 12:35:30 -0700 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <4AAA9A63.2010200@sun.com> References: <20090911162252.501B95B8@eggemoggin.niobe.net> <4AAA8847.4060409@sun.com> <4AAA8928.7030204@sun.com> <4AAA9126.2030308@sun.com> <4AAA9A63.2010200@sun.com> Message-ID: <4AAAA682.8060703@sun.com> Push has finished. -kto Joseph D. Darcy wrote: > Thanks Kelly, > > -Joe > > Kelly O'Hair wrote: >> Pushing now... or should I say >> ppppppuuuuuuusssssssshhhhhhhiiiiiinnnnnggggggg >> nnnnnnnnnooooooooooowwwwwwwwwww >> >> It's very slow. :^( >> >> Hopefully in the next 30mins... >> >> -kto >> >> Joseph D. Darcy wrote: >>> Kelly, >>> >>> Yes, please file a bug and push the changes; I approve these changes >>> going back. >>> >>> -Joe >>> >>> Kelly O'Hair wrote: >>>> I think a bugid will be needed to push in the changesets that >>>> change the .jcheck/conf files in jdk6, shall I file one? >>>> One bugid should cover all of the jdk6 repositories. >>>> >>>> And I could push the changes in if need be, just say the word. >>>> >>>> -kto >>>> >>>> Mark Reinhold wrote: >>>>> I've updated the jcheck extension to allow the unique-bugid >>>>> restriction to be disabled, and I've disabled that check in >>>>> the jdk6 forest. >>>>> >>>>> Joe: For the benefit of those using jcheck in their working >>>>> repos I suggest you update the .jcheck/conf file in each repo >>>>> to read: >>>>> >>>>> project=jdk6 >>>>> whitespace=lax >>>>> comments=lax >>>>> bugids=dup >>>>> >>>>> As for the extension itself, I'm working to get it published >>>>> externally, hopefully in the next week or two. >>>>> >>>>> - Mark >>> > From karen.kinnear at sun.com Fri Sep 11 16:03:26 2009 From: karen.kinnear at sun.com (karen.kinnear at sun.com) Date: Fri, 11 Sep 2009 23:03:26 +0000 Subject: hg: hsx/hsx16/baseline: 6879572: SA fails with "RuntimeException: field "_is_marked_dependent" not found Message-ID: <20090911230331.25D261203D@hg.openjdk.java.net> Changeset: f00a893fee8c Author: acorn Date: 2009-09-11 13:41 -0400 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/f00a893fee8c 6879572: SA fails with "RuntimeException: field "_is_marked_dependent" not found Reviewed-by: dcubed, kamg ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp From gnu_andrew at member.fsf.org Sat Sep 12 04:54:36 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sat, 12 Sep 2009 12:54:36 +0100 Subject: PING 3: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <19114.39417.509560.251572@sun.com> References: <17c6771e0909041021j10a046f0l5eec2e765bbe32e5@mail.gmail.com> <19105.21641.434524.306543@sun.com> <17c6771e0909041203x7b405e78pbc1586c3d26f5504@mail.gmail.com> <19105.63930.845263.728467@sun.com> <17c6771e0909060642y38631c09xf86f1121d938bb38@mail.gmail.com> <17c6771e0909070717k60d2be5cpce809698dc5aa0cb@mail.gmail.com> <19113.39846.175760.81942@sun.com> <17c6771e0909110907qd4b1b44wf43aa15fa8b729a5@mail.gmail.com> <19114.39417.509560.251572@sun.com> Message-ID: <17c6771e0909120454m48172b3ao3c6b3e07a10ffa3f@mail.gmail.com> 2009/9/11 John Coomes : > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: >> 2009/9/11 John Coomes : >> > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: >> >> > ... >> >> > Ok so this sounds like we need to go back to something similar to what >> >> > I started with, and patch each individual platform Makefile. ????Is that >> >> > correct? >> >> >> >> Here's a revised webrev: >> >> >> >> http://cr.openjdk.java.net/~andrew/ecj/03/webrev.05/hotspot.patch >> >> >> >> using rules.make for each platform instead of the top-level defs.make. >> >> It also includes the replacement of separate SA flags with just adding >> >> the same flags to SA and then following that with -source/target 1.4. >> >> Is this ok? >> > >> > Looks good so far. ??I'm trying some builds. >> > >> >> Ok, the patch you gave below looks ok to me. ?Are you testing with >> this patched version? >> Let me know if it goes ok, and if it does I'll push the patched version. > > I tested both on solaris & linux (all good). ?I'll also try windows > shortly. > > Note that we (hotspot) use an auto-build system called jprt for all > changes; it builds & tests on all platforms and does the push if > everything is clean. ?If you create a changeset that jcheck will > accept I'll submit it for you to jprt. ?Include me as a reviewer > (jcoomes). > > You can publish the repo or generate a patch w/hg headers using 'hg > export'. > > -John > >> >> >> Also, in prior email I suggested: >> >> >> >> >> >>> ..., if you update JAVAC_COMPILE to include BOOTSTRAP_JAVAC_FLAGS (or >> >> >>> whatever it is), and the SA makefile also includes -source/-target >> >> >>> options on the command-line, the latter will override the ones in >> >> >>> BOOTSTRAP_JAVAC_FLAGS (the SA command line may need to include both >> >> >>> -source and -target). ????At least try it, I think it'll be a simpler change. >> >> >> >> >> > >> >> > Ok, I must have missed this. ????It sounds a good idea and in the long >> >> > term I presume we want to get rid of the SA overrides anyway. >> > >> > That's closer, but not exactly what I was suggesting. ??Here's a patch >> > to apply on top of your patch. ??Basically, it includes >> > BOOTSTRAP_JAVAC_FLAGS in COMPILE.JAVAC (COMPILE_JAVAC on windows). >> > >> > -John >> > >> > >> > # HG changeset patch >> > # User jcoomes >> > # Date 1252627237 25200 >> > >> > diff --git a/make/linux/makefiles/jvmti.make b/make/linux/makefiles/jvmti.make >> > --- a/make/linux/makefiles/jvmti.make >> > +++ b/make/linux/makefiles/jvmti.make >> > @@ -70,10 +70,10 @@ >> > ??both = $(JvmtiGenClass) $(JvmtiSrcDir)/jvmti.xml $(JvmtiSrcDir)/jvmtiLib.xsl >> > >> > ??$(JvmtiGenClass): $(JvmtiGenSource) >> > - ?? ?? ?? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -d $(JvmtiOutDir) $(JvmtiGenSource) >> > + ?? ?? ?? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -d $(JvmtiOutDir) $(JvmtiGenSource) >> > >> > ??$(JvmtiEnvFillClass): $(JvmtiEnvFillSource) >> > - ?? ?? ?? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) >> > + ?? ?? ?? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) >> > >> > ??$(JvmtiOutDir)/jvmtiEnter.cpp: $(both) $(JvmtiSrcDir)/jvmtiEnter.xsl >> > ?? ?? ?? ??@echo Generating $@ >> > diff --git a/make/linux/makefiles/rules.make b/make/linux/makefiles/rules.make >> > --- a/make/linux/makefiles/rules.make >> > +++ b/make/linux/makefiles/rules.make >> > @@ -122,6 +122,8 @@ >> > ??endif >> > ??endif >> > >> > +COMPILE.JAVAC += $(BOOTSTRAP_JAVAC_FLAGS) >> > + >> > ??SUM = /usr/bin/sum >> > >> > ??# 'gmake MAKE_VERBOSE=y' gives all the gory details. >> > diff --git a/make/linux/makefiles/sa.make b/make/linux/makefiles/sa.make >> > --- a/make/linux/makefiles/sa.make >> > +++ b/make/linux/makefiles/sa.make >> > @@ -74,8 +74,8 @@ >> > ?? ?? ?? ?? ??mkdir -p $(SA_CLASSDIR); ?? ?? ?? ??\ >> > ?? ?? ?? ??fi >> > >> > - ?? ?? ?? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1) >> > - ?? ?? ?? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2) >> > + ?? ?? ?? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1) >> > + ?? ?? ?? $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2) >> > >> > ?? ?? ?? ??$(QUIETLY) $(REMOTE) $(COMPILE.RMIC) ??-classpath $(SA_CLASSDIR) -d $(SA_CLASSDIR) sun.jvm.hotspot.debugger.remote.RemoteDebuggerServer >> > ?? ?? ?? ??$(QUIETLY) echo "$(SA_BUILD_VERSION_PROP)" > $(SA_PROPERTIES) >> > diff --git a/make/linux/makefiles/top.make b/make/linux/makefiles/top.make >> > --- a/make/linux/makefiles/top.make >> > +++ b/make/linux/makefiles/top.make >> > @@ -114,7 +114,7 @@ >> > ??# make makeDeps: (and zap the cached db files to force a nonincremental run) >> > >> > ??$(GENERATED)/$(MakeDepsClass): $(MakeDepsSources) >> > - ?? ?? ?? @$(REMOTE) $(COMPILE.JAVAC) -classpath $(GAMMADIR)/src/share/tools/MakeDeps $(BOOTSTRAP_JAVAC_FLAGS) -d $(GENERATED) $(MakeDepsSources) >> > + ?? ?? ?? @$(REMOTE) $(COMPILE.JAVAC) -classpath $(GAMMADIR)/src/share/tools/MakeDeps -d $(GENERATED) $(MakeDepsSources) >> > ?? ?? ?? ??@echo Removing $(Incremental_Lists) to force regeneration. >> > ?? ?? ?? ??@rm -f $(Incremental_Lists) >> > ?? ?? ?? ??@$(CDG) echo >$(Cached_plat) >> > diff --git a/make/solaris/makefiles/jvmti.make b/make/solaris/makefiles/jvmti.make >> > --- a/make/solaris/makefiles/jvmti.make >> > +++ b/make/solaris/makefiles/jvmti.make >> > @@ -69,10 +69,10 @@ >> > ??both = $(JvmtiGenClass) $(JvmtiSrcDir)/jvmti.xml $(JvmtiSrcDir)/jvmtiLib.xsl >> > >> > ??$(JvmtiGenClass): $(JvmtiGenSource) >> > - ?? ?? ?? $(QUIETLY) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -d $(JvmtiOutDir) $(JvmtiGenSource) >> > + ?? ?? ?? $(QUIETLY) $(COMPILE.JAVAC) -d $(JvmtiOutDir) $(JvmtiGenSource) >> > >> > ??$(JvmtiEnvFillClass): $(JvmtiEnvFillSource) >> > - ?? ?? ?? $(QUIETLY) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) >> > + ?? ?? ?? $(QUIETLY) $(COMPILE.JAVAC) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) >> > >> > ??$(JvmtiOutDir)/jvmtiEnter.cpp: $(both) $(JvmtiSrcDir)/jvmtiEnter.xsl >> > ?? ?? ?? ??@echo Generating $@ >> > diff --git a/make/solaris/makefiles/rules.make b/make/solaris/makefiles/rules.make >> > --- a/make/solaris/makefiles/rules.make >> > +++ b/make/solaris/makefiles/rules.make >> > @@ -122,6 +122,8 @@ >> > ??endif >> > ??endif >> > >> > +COMPILE.JAVAC += $(BOOTSTRAP_JAVAC_FLAGS) >> > + >> > ??SUM = /usr/bin/sum >> > >> > ??# 'gmake MAKE_VERBOSE=y' gives all the gory details. >> > diff --git a/make/solaris/makefiles/sa.make b/make/solaris/makefiles/sa.make >> > --- a/make/solaris/makefiles/sa.make >> > +++ b/make/solaris/makefiles/sa.make >> > @@ -67,9 +67,9 @@ >> > ?? ?? ?? ??$(QUIETLY) if [ ! -d $(SA_CLASSDIR) ] ; then \ >> > ?? ?? ?? ?? ??mkdir -p $(SA_CLASSDIR); ?? ?? ?? ??\ >> > ?? ?? ?? ??fi >> > - ?? ?? ?? $(QUIETLY) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1) >> > - ?? ?? ?? $(QUIETLY) $(COMPILE.JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2) >> > - >> > + ?? ?? ?? $(QUIETLY) $(COMPILE.JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1) >> > + ?? ?? ?? $(QUIETLY) $(COMPILE.JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2) >> > + >> > ?? ?? ?? ??$(QUIETLY) $(COMPILE.RMIC) ??-classpath $(SA_CLASSDIR) -d $(SA_CLASSDIR) sun.jvm.hotspot.debugger.remote.RemoteDebuggerServer >> > ?? ?? ?? ??$(QUIETLY) echo "$(SA_BUILD_VERSION_PROP)" > $(SA_PROPERTIES) >> > ?? ?? ?? ??$(QUIETLY) rm -f $(SA_CLASSDIR)/sun/jvm/hotspot/utilities/soql/sa.js >> > diff --git a/make/solaris/makefiles/top.make b/make/solaris/makefiles/top.make >> > --- a/make/solaris/makefiles/top.make >> > +++ b/make/solaris/makefiles/top.make >> > @@ -112,7 +112,7 @@ >> > ??# make makeDeps: (and zap the cached db files to force a nonincremental run) >> > >> > ??$(GENERATED)/$(MakeDepsClass): $(MakeDepsSources) >> > - ?? ?? ?? @$(COMPILE.JAVAC) -classpath $(GAMMADIR)/src/share/tools/MakeDeps $(BOOTSTRAP_JAVAC_FLAGS) -d $(GENERATED) $(MakeDepsSources) >> > + ?? ?? ?? @$(COMPILE.JAVAC) -classpath $(GAMMADIR)/src/share/tools/MakeDeps -d $(GENERATED) $(MakeDepsSources) >> > ?? ?? ?? ??@echo Removing $(Incremental_Lists) to force regeneration. >> > ?? ?? ?? ??@rm -f $(Incremental_Lists) >> > ?? ?? ?? ??@$(CDG) echo >$(Cached_plat) >> > diff --git a/make/windows/makefiles/generated.make b/make/windows/makefiles/generated.make >> > --- a/make/windows/makefiles/generated.make >> > +++ b/make/windows/makefiles/generated.make >> > @@ -91,7 +91,7 @@ >> > ??classes/MakeDeps.class: $(MakeDepsSources) >> > ?? ?? ?? ??if exist classes rmdir /s /q classes >> > ?? ?? ?? ??mkdir classes >> > - ?? ?? ?? $(COMPILE_JAVAC) -classpath $(WorkSpace)\src\share\tools\MakeDeps $(BOOTSTRAP_JAVAC_FLAGS) -d classes $(MakeDepsSources) >> > + ?? ?? ?? $(COMPILE_JAVAC) -classpath $(WorkSpace)\src\share\tools\MakeDeps -d classes $(MakeDepsSources) >> > >> > ??!if ("$(Variant)" == "compiler2") || ("$(Variant)" == "tiered") >> > >> > diff --git a/make/windows/makefiles/jvmti.make b/make/windows/makefiles/jvmti.make >> > --- a/make/windows/makefiles/jvmti.make >> > +++ b/make/windows/makefiles/jvmti.make >> > @@ -68,10 +68,10 @@ >> > ?? ?? ?? ?? @if not exist $(JvmtiOutDir) mkdir $(JvmtiOutDir) >> > >> > ??$(JvmtiGenClass): $(JvmtiGenSource) >> > - ?? ?? ?? $(COMPILE_JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -d $(JvmtiOutDir) $(JvmtiGenSource) >> > + ?? ?? ?? $(COMPILE_JAVAC) -d $(JvmtiOutDir) $(JvmtiGenSource) >> > >> > ??$(JvmtiEnvFillClass): $(JvmtiEnvFillSource) >> > - ?? ?? ?? @$(COMPILE_JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) >> > + ?? ?? ?? @$(COMPILE_JAVAC) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) >> > >> > ??$(JvmtiOutDir)/jvmtiEnter.cpp: $(both) $(JvmtiSrcDir)/jvmtiEnter.xsl >> > ?? ?? ?? ??@echo Generating $@ >> > diff --git a/make/windows/makefiles/rules.make b/make/windows/makefiles/rules.make >> > --- a/make/windows/makefiles/rules.make >> > +++ b/make/windows/makefiles/rules.make >> > @@ -29,7 +29,7 @@ >> > ??RUN_JAVAP=$(BootStrapDir)\bin\javap >> > ??RUN_JAVAH=$(BootStrapDir)\bin\javah >> > ??RUN_JAR=$(BootStrapDir)\bin\jar >> > -COMPILE_JAVAC=$(BootStrapDir)\bin\javac >> > +COMPILE_JAVAC=$(BootStrapDir)\bin\javac $(BOOTSTRAP_JAVAC_FLAGS) >> > ??COMPILE_RMIC=$(BootStrapDir)\bin\rmic >> > ??BOOT_JAVA_HOME=$(BootStrapDir) >> > ??!else >> > @@ -37,7 +37,7 @@ >> > ??RUN_JAVAP=javap >> > ??RUN_JAVAH=javah >> > ??RUN_JAR=jar >> > -COMPILE_JAVAC=javac >> > +COMPILE_JAVAC=javac $(BOOTSTRAP_JAVAC_FLAGS) >> > ??COMPILE_RMIC=rmic >> > ??BOOT_JAVA_HOME= >> > ??!endif >> > diff --git a/make/windows/makefiles/sa.make b/make/windows/makefiles/sa.make >> > --- a/make/windows/makefiles/sa.make >> > +++ b/make/windows/makefiles/sa.make >> > @@ -55,9 +55,9 @@ >> > ??$(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\) >> > ?? ?? ?? ??@if not exist $(SA_CLASSDIR) mkdir $(SA_CLASSDIR) >> > ?? ?? ?? ??@echo ...Building sa-jdi.jar >> > - ?? ?? ?? @echo ...$(COMPILE_JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -d $(SA_CLASSDIR) .... >> > - ?? ?? ?? @$(COMPILE_JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\) >> > - ?? ?? ?? @$(COMPILE_JAVAC) $(BOOTSTRAP_JAVAC_FLAGS) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\) >> > + ?? ?? ?? @echo ...$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -d $(SA_CLASSDIR) .... >> > + ?? ?? ?? @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\) >> > + ?? ?? ?? @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\) >> > ?? ?? ?? ??$(COMPILE_RMIC) -classpath $(SA_CLASSDIR) -d $(SA_CLASSDIR) sun.jvm.hotspot.debugger.remote.RemoteDebuggerServer >> > ?? ?? ?? ??$(QUIETLY) echo $(SA_BUILD_VERSION_PROP)> $(SA_PROPERTIES) >> > ?? ?? ?? ??$(QUIETLY) rm -f $(SA_CLASSDIR)/sun/jvm/hotspot/utilities/soql/sa.js >> > diff --git a/make/windows/projectfiles/common/Makefile b/make/windows/projectfiles/common/Makefile >> > --- a/make/windows/projectfiles/common/Makefile >> > +++ b/make/windows/projectfiles/common/Makefile >> > @@ -179,6 +179,6 @@ >> > ??$(HOTSPOTBUILDSPACE)/classes/MakeDeps.class: $(MakeDepsSources) >> > ?? ?? ?? ??@if exist $(HOTSPOTBUILDSPACE)\classes rmdir /s /q $(HOTSPOTBUILDSPACE)\classes >> > ?? ?? ?? ??@mkdir $(HOTSPOTBUILDSPACE)\classes >> > - ?? ?? ?? @$(COMPILE_JAVAC) -classpath $(HOTSPOTWORKSPACE)\src\share\tools\MakeDeps $(BOOTSTRAP_JAVAC_FLAGS) -d $(HOTSPOTBUILDSPACE)/classes $(MakeDepsSources) >> > + ?? ?? ?? @$(COMPILE_JAVAC) -classpath $(HOTSPOTWORKSPACE)\src\share\tools\MakeDeps -d $(HOTSPOTBUILDSPACE)/classes $(MakeDepsSources) >> > >> > ??FORCE: >> > >> > >> >> >> >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > > The exported patch is attached. It builds for me, so I hope all finally goes well with the push :) -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 -------------- next part -------------- # HG changeset patch # User andrew # Date 1252756207 -3600 # Node ID b165c44c8afb41415b84b062244a1f94040e2961 # Parent 0804a88ed4f54330d551761fc1226a818ba5a455 6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk Summary: The build fails if the bootstrap JDK defaults to <1.5 Reviewed-by: jcoomes Contributed-by: Andrew John Hughes diff -r 0804a88ed4f5 -r b165c44c8afb make/linux/makefiles/jvmti.make --- a/make/linux/makefiles/jvmti.make Tue Sep 08 09:02:48 2009 +0100 +++ b/make/linux/makefiles/jvmti.make Sat Sep 12 12:50:07 2009 +0100 @@ -70,10 +70,10 @@ both = $(JvmtiGenClass) $(JvmtiSrcDir)/jvmti.xml $(JvmtiSrcDir)/jvmtiLib.xsl $(JvmtiGenClass): $(JvmtiGenSource) - $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -g -d $(JvmtiOutDir) $(JvmtiGenSource) + $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -d $(JvmtiOutDir) $(JvmtiGenSource) $(JvmtiEnvFillClass): $(JvmtiEnvFillSource) - $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -g -d $(JvmtiOutDir) $(JvmtiEnvFillSource) + $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) $(JvmtiOutDir)/jvmtiEnter.cpp: $(both) $(JvmtiSrcDir)/jvmtiEnter.xsl @echo Generating $@ diff -r 0804a88ed4f5 -r b165c44c8afb make/linux/makefiles/rules.make --- a/make/linux/makefiles/rules.make Tue Sep 08 09:02:48 2009 +0100 +++ b/make/linux/makefiles/rules.make Sat Sep 12 12:50:07 2009 +0100 @@ -122,12 +122,20 @@ endif endif +COMPILE.JAVAC += $(BOOTSTRAP_JAVAC_FLAGS) + SUM = /usr/bin/sum # 'gmake MAKE_VERBOSE=y' gives all the gory details. QUIETLY$(MAKE_VERBOSE) = @ RUN.JAR$(MAKE_VERBOSE) += >/dev/null +# Settings for javac +BOOT_SOURCE_LANGUAGE_VERSION = 6 +BOOT_TARGET_CLASS_VERSION = 6 +JAVAC_FLAGS = -g -encoding ascii +BOOTSTRAP_JAVAC_FLAGS = $(JAVAC_FLAGS) -source $(BOOT_SOURCE_LANGUAGE_VERSION) -target $(BOOT_TARGET_CLASS_VERSION) + # With parallel makes, print a message at the end of compilation. ifeq ($(findstring j,$(MFLAGS)),j) COMPILE_DONE = && { echo Done with $<; } diff -r 0804a88ed4f5 -r b165c44c8afb make/linux/makefiles/sa.make --- a/make/linux/makefiles/sa.make Tue Sep 08 09:02:48 2009 +0100 +++ b/make/linux/makefiles/sa.make Sat Sep 12 12:50:07 2009 +0100 @@ -74,8 +74,8 @@ mkdir -p $(SA_CLASSDIR); \ fi - $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -source 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -g -d $(SA_CLASSDIR) $(AGENT_FILES1) - $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -source 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -g -d $(SA_CLASSDIR) $(AGENT_FILES2) + $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1) + $(QUIETLY) $(REMOTE) $(COMPILE.JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2) $(QUIETLY) $(REMOTE) $(COMPILE.RMIC) -classpath $(SA_CLASSDIR) -d $(SA_CLASSDIR) sun.jvm.hotspot.debugger.remote.RemoteDebuggerServer $(QUIETLY) echo "$(SA_BUILD_VERSION_PROP)" > $(SA_PROPERTIES) diff -r 0804a88ed4f5 -r b165c44c8afb make/linux/makefiles/top.make --- a/make/linux/makefiles/top.make Tue Sep 08 09:02:48 2009 +0100 +++ b/make/linux/makefiles/top.make Sat Sep 12 12:50:07 2009 +0100 @@ -24,7 +24,7 @@ # top.make is included in the Makefile in the build directories. # It DOES NOT include the vm dependency info in order to be faster. -# It's main job is to implement the incremental form of make lists. +# Its main job is to implement the incremental form of make lists. # It also: # -builds and runs adlc via adlc.make # -generates JVMTI source and docs via jvmti.make (JSR-163) @@ -114,7 +114,7 @@ # make makeDeps: (and zap the cached db files to force a nonincremental run) $(GENERATED)/$(MakeDepsClass): $(MakeDepsSources) - @$(REMOTE) $(COMPILE.JAVAC) -classpath $(GAMMADIR)/src/share/tools/MakeDeps -g -d $(GENERATED) $(MakeDepsSources) + @$(REMOTE) $(COMPILE.JAVAC) -classpath $(GAMMADIR)/src/share/tools/MakeDeps -d $(GENERATED) $(MakeDepsSources) @echo Removing $(Incremental_Lists) to force regeneration. @rm -f $(Incremental_Lists) @$(CDG) echo >$(Cached_plat) diff -r 0804a88ed4f5 -r b165c44c8afb make/solaris/makefiles/jvmti.make --- a/make/solaris/makefiles/jvmti.make Tue Sep 08 09:02:48 2009 +0100 +++ b/make/solaris/makefiles/jvmti.make Sat Sep 12 12:50:07 2009 +0100 @@ -69,10 +69,10 @@ both = $(JvmtiGenClass) $(JvmtiSrcDir)/jvmti.xml $(JvmtiSrcDir)/jvmtiLib.xsl $(JvmtiGenClass): $(JvmtiGenSource) - $(QUIETLY) $(COMPILE.JAVAC) -g -d $(JvmtiOutDir) $(JvmtiGenSource) + $(QUIETLY) $(COMPILE.JAVAC) -d $(JvmtiOutDir) $(JvmtiGenSource) $(JvmtiEnvFillClass): $(JvmtiEnvFillSource) - $(QUIETLY) $(COMPILE.JAVAC) -g -d $(JvmtiOutDir) $(JvmtiEnvFillSource) + $(QUIETLY) $(COMPILE.JAVAC) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) $(JvmtiOutDir)/jvmtiEnter.cpp: $(both) $(JvmtiSrcDir)/jvmtiEnter.xsl @echo Generating $@ diff -r 0804a88ed4f5 -r b165c44c8afb make/solaris/makefiles/rules.make --- a/make/solaris/makefiles/rules.make Tue Sep 08 09:02:48 2009 +0100 +++ b/make/solaris/makefiles/rules.make Sat Sep 12 12:50:07 2009 +0100 @@ -122,12 +122,20 @@ endif endif +COMPILE.JAVAC += $(BOOTSTRAP_JAVAC_FLAGS) + SUM = /usr/bin/sum # 'gmake MAKE_VERBOSE=y' gives all the gory details. QUIETLY$(MAKE_VERBOSE) = @ RUN.JAR$(MAKE_VERBOSE) += >/dev/null +# Settings for javac +BOOT_SOURCE_LANGUAGE_VERSION = 6 +BOOT_TARGET_CLASS_VERSION = 6 +JAVAC_FLAGS = -g -encoding ascii +BOOTSTRAP_JAVAC_FLAGS = $(JAVAC_FLAGS) -source $(BOOT_SOURCE_LANGUAGE_VERSION) -target $(BOOT_TARGET_CLASS_VERSION) + # With parallel makes, print a message at the end of compilation. ifeq ($(findstring j,$(MFLAGS)),j) COMPILE_DONE = && { echo Done with $<; } diff -r 0804a88ed4f5 -r b165c44c8afb make/solaris/makefiles/sa.make --- a/make/solaris/makefiles/sa.make Tue Sep 08 09:02:48 2009 +0100 +++ b/make/solaris/makefiles/sa.make Sat Sep 12 12:50:07 2009 +0100 @@ -67,8 +67,8 @@ $(QUIETLY) if [ ! -d $(SA_CLASSDIR) ] ; then \ mkdir -p $(SA_CLASSDIR); \ fi - $(QUIETLY) $(COMPILE.JAVAC) -source 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -g -d $(SA_CLASSDIR) $(AGENT_FILES1) - $(QUIETLY) $(COMPILE.JAVAC) -source 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -g -d $(SA_CLASSDIR) $(AGENT_FILES2) + $(QUIETLY) $(COMPILE.JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1) + $(QUIETLY) $(COMPILE.JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2) $(QUIETLY) $(COMPILE.RMIC) -classpath $(SA_CLASSDIR) -d $(SA_CLASSDIR) sun.jvm.hotspot.debugger.remote.RemoteDebuggerServer $(QUIETLY) echo "$(SA_BUILD_VERSION_PROP)" > $(SA_PROPERTIES) diff -r 0804a88ed4f5 -r b165c44c8afb make/solaris/makefiles/top.make --- a/make/solaris/makefiles/top.make Tue Sep 08 09:02:48 2009 +0100 +++ b/make/solaris/makefiles/top.make Sat Sep 12 12:50:07 2009 +0100 @@ -24,7 +24,7 @@ # top.make is included in the Makefile in the build directories. # It DOES NOT include the vm dependency info in order to be faster. -# It's main job is to implement the incremental form of make lists. +# Its main job is to implement the incremental form of make lists. # It also: # -builds and runs adlc via adlc.make # -generates JVMTI source and docs via jvmti.make (JSR-163) @@ -112,7 +112,7 @@ # make makeDeps: (and zap the cached db files to force a nonincremental run) $(GENERATED)/$(MakeDepsClass): $(MakeDepsSources) - @$(COMPILE.JAVAC) -classpath $(GAMMADIR)/src/share/tools/MakeDeps -g -d $(GENERATED) $(MakeDepsSources) + @$(COMPILE.JAVAC) -classpath $(GAMMADIR)/src/share/tools/MakeDeps -d $(GENERATED) $(MakeDepsSources) @echo Removing $(Incremental_Lists) to force regeneration. @rm -f $(Incremental_Lists) @$(CDG) echo >$(Cached_plat) diff -r 0804a88ed4f5 -r b165c44c8afb make/windows/makefiles/generated.make --- a/make/windows/makefiles/generated.make Tue Sep 08 09:02:48 2009 +0100 +++ b/make/windows/makefiles/generated.make Sat Sep 12 12:50:07 2009 +0100 @@ -91,7 +91,7 @@ classes/MakeDeps.class: $(MakeDepsSources) if exist classes rmdir /s /q classes mkdir classes - $(COMPILE_JAVAC) -classpath $(WorkSpace)\src\share\tools\MakeDeps -g -d classes $(MakeDepsSources) + $(COMPILE_JAVAC) -classpath $(WorkSpace)\src\share\tools\MakeDeps -d classes $(MakeDepsSources) !if ("$(Variant)" == "compiler2") || ("$(Variant)" == "tiered") diff -r 0804a88ed4f5 -r b165c44c8afb make/windows/makefiles/jvmti.make --- a/make/windows/makefiles/jvmti.make Tue Sep 08 09:02:48 2009 +0100 +++ b/make/windows/makefiles/jvmti.make Sat Sep 12 12:50:07 2009 +0100 @@ -68,10 +68,10 @@ @if not exist $(JvmtiOutDir) mkdir $(JvmtiOutDir) $(JvmtiGenClass): $(JvmtiGenSource) - $(COMPILE_JAVAC) -g -d $(JvmtiOutDir) $(JvmtiGenSource) + $(COMPILE_JAVAC) -d $(JvmtiOutDir) $(JvmtiGenSource) $(JvmtiEnvFillClass): $(JvmtiEnvFillSource) - @$(COMPILE_JAVAC) -g -d $(JvmtiOutDir) $(JvmtiEnvFillSource) + @$(COMPILE_JAVAC) -d $(JvmtiOutDir) $(JvmtiEnvFillSource) $(JvmtiOutDir)/jvmtiEnter.cpp: $(both) $(JvmtiSrcDir)/jvmtiEnter.xsl @echo Generating $@ diff -r 0804a88ed4f5 -r b165c44c8afb make/windows/makefiles/rules.make --- a/make/windows/makefiles/rules.make Tue Sep 08 09:02:48 2009 +0100 +++ b/make/windows/makefiles/rules.make Sat Sep 12 12:50:07 2009 +0100 @@ -29,7 +29,7 @@ RUN_JAVAP=$(BootStrapDir)\bin\javap RUN_JAVAH=$(BootStrapDir)\bin\javah RUN_JAR=$(BootStrapDir)\bin\jar -COMPILE_JAVAC=$(BootStrapDir)\bin\javac +COMPILE_JAVAC=$(BootStrapDir)\bin\javac $(BOOTSTRAP_JAVAC_FLAGS) COMPILE_RMIC=$(BootStrapDir)\bin\rmic BOOT_JAVA_HOME=$(BootStrapDir) !else @@ -37,11 +37,17 @@ RUN_JAVAP=javap RUN_JAVAH=javah RUN_JAR=jar -COMPILE_JAVAC=javac +COMPILE_JAVAC=javac $(BOOTSTRAP_JAVAC_FLAGS) COMPILE_RMIC=rmic BOOT_JAVA_HOME= !endif +# Settings for javac +BOOT_SOURCE_LANGUAGE_VERSION=6 +BOOT_TARGET_CLASS_VERSION=6 +JAVAC_FLAGS=-g -encoding ascii +BOOTSTRAP_JAVAC_FLAGS=$(JAVAC_FLAGS) -source $(BOOT_SOURCE_LANGUAGE_VERSION) -target $(BOOT_TARGET_CLASS_VERSION) + ProjectFile=vm.vcproj !if "$(MSC_VER)" == "1200" diff -r 0804a88ed4f5 -r b165c44c8afb make/windows/makefiles/sa.make --- a/make/windows/makefiles/sa.make Tue Sep 08 09:02:48 2009 +0100 +++ b/make/windows/makefiles/sa.make Sat Sep 12 12:50:07 2009 +0100 @@ -55,9 +55,9 @@ $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\) @if not exist $(SA_CLASSDIR) mkdir $(SA_CLASSDIR) @echo ...Building sa-jdi.jar - @echo ...$(COMPILE_JAVAC) -source 1.4 -classpath $(SA_CLASSPATH) -g -d $(SA_CLASSDIR) .... - @$(COMPILE_JAVAC) -source 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -g -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\) - @$(COMPILE_JAVAC) -source 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -g -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\) + @echo ...$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -d $(SA_CLASSDIR) .... + @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\) + @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -sourcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\) $(COMPILE_RMIC) -classpath $(SA_CLASSDIR) -d $(SA_CLASSDIR) sun.jvm.hotspot.debugger.remote.RemoteDebuggerServer $(QUIETLY) echo $(SA_BUILD_VERSION_PROP)> $(SA_PROPERTIES) $(QUIETLY) rm -f $(SA_CLASSDIR)/sun/jvm/hotspot/utilities/soql/sa.js diff -r 0804a88ed4f5 -r b165c44c8afb make/windows/projectfiles/common/Makefile --- a/make/windows/projectfiles/common/Makefile Tue Sep 08 09:02:48 2009 +0100 +++ b/make/windows/projectfiles/common/Makefile Sat Sep 12 12:50:07 2009 +0100 @@ -179,6 +179,6 @@ $(HOTSPOTBUILDSPACE)/classes/MakeDeps.class: $(MakeDepsSources) @if exist $(HOTSPOTBUILDSPACE)\classes rmdir /s /q $(HOTSPOTBUILDSPACE)\classes @mkdir $(HOTSPOTBUILDSPACE)\classes - @$(COMPILE_JAVAC) -classpath $(HOTSPOTWORKSPACE)\src\share\tools\MakeDeps -g -d $(HOTSPOTBUILDSPACE)/classes $(MakeDepsSources) + @$(COMPILE_JAVAC) -classpath $(HOTSPOTWORKSPACE)\src\share\tools\MakeDeps -d $(HOTSPOTBUILDSPACE)/classes $(MakeDepsSources) FORCE: From gnu_andrew at member.fsf.org Sat Sep 12 04:56:54 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sat, 12 Sep 2009 12:56:54 +0100 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <4AAAA682.8060703@sun.com> References: <20090911162252.501B95B8@eggemoggin.niobe.net> <4AAA8847.4060409@sun.com> <4AAA8928.7030204@sun.com> <4AAA9126.2030308@sun.com> <4AAA9A63.2010200@sun.com> <4AAAA682.8060703@sun.com> Message-ID: <17c6771e0909120456l664ef0b8u8e25be6976b2763b@mail.gmail.com> 2009/9/11 Kelly O'Hair : > Push has finished. > > -kto > > Joseph D. Darcy wrote: >> >> Thanks Kelly, >> >> -Joe >> >> Kelly O'Hair wrote: >>> >>> Pushing now... or should I say >>> ppppppuuuuuuusssssssshhhhhhhiiiiiinnnnnggggggg >>> ?nnnnnnnnnooooooooooowwwwwwwwwww >>> >>> It's very slow. :^( >>> >>> Hopefully in the next 30mins... >>> >>> -kto >>> >>> Joseph D. Darcy wrote: >>>> >>>> Kelly, >>>> >>>> Yes, please file a bug and push the changes; I approve these changes >>>> going back. >>>> >>>> -Joe >>>> >>>> Kelly O'Hair wrote: >>>>> >>>>> I think a bugid will be needed to push in the changesets that >>>>> change the .jcheck/conf files in jdk6, shall I file one? >>>>> One bugid should cover all of the jdk6 repositories. >>>>> >>>>> And I could push the changes in if need be, just say the word. >>>>> >>>>> -kto >>>>> >>>>> Mark Reinhold wrote: >>>>>> >>>>>> I've updated the jcheck extension to allow the unique-bugid >>>>>> restriction to be disabled, and I've disabled that check in >>>>>> the jdk6 forest. >>>>>> >>>>>> Joe: For the benefit of those using jcheck in their working >>>>>> repos I suggest you update the .jcheck/conf file in each repo >>>>>> to read: >>>>>> >>>>>> ? ?project=jdk6 >>>>>> ? ?whitespace=lax >>>>>> ? ?comments=lax >>>>>> ? ?bugids=dup >>>>>> >>>>>> As for the extension itself, I'm working to get it published >>>>>> externally, hopefully in the next week or two. >>>>>> >>>>>> - Mark >>>> >> > http://mail.openjdk.java.net/pipermail/jdk6-dev/2009-September/000772.html Subject: hg: jdk6/jdk6/hotspot: 557 new changesets Woohoo! -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Sat Sep 12 04:57:30 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sat, 12 Sep 2009 12:57:30 +0100 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <17c6771e0909120456l664ef0b8u8e25be6976b2763b@mail.gmail.com> References: <20090911162252.501B95B8@eggemoggin.niobe.net> <4AAA8847.4060409@sun.com> <4AAA8928.7030204@sun.com> <4AAA9126.2030308@sun.com> <4AAA9A63.2010200@sun.com> <4AAAA682.8060703@sun.com> <17c6771e0909120456l664ef0b8u8e25be6976b2763b@mail.gmail.com> Message-ID: <17c6771e0909120457u7bbfb444h39d69c57630a143e@mail.gmail.com> 2009/9/12 Andrew John Hughes : > 2009/9/11 Kelly O'Hair : >> Push has finished. >> >> -kto >> >> Joseph D. Darcy wrote: >>> >>> Thanks Kelly, >>> >>> -Joe >>> >>> Kelly O'Hair wrote: >>>> >>>> Pushing now... or should I say >>>> ppppppuuuuuuusssssssshhhhhhhiiiiiinnnnnggggggg >>>> ?nnnnnnnnnooooooooooowwwwwwwwwww >>>> >>>> It's very slow. :^( >>>> >>>> Hopefully in the next 30mins... >>>> >>>> -kto >>>> >>>> Joseph D. Darcy wrote: >>>>> >>>>> Kelly, >>>>> >>>>> Yes, please file a bug and push the changes; I approve these changes >>>>> going back. >>>>> >>>>> -Joe >>>>> >>>>> Kelly O'Hair wrote: >>>>>> >>>>>> I think a bugid will be needed to push in the changesets that >>>>>> change the .jcheck/conf files in jdk6, shall I file one? >>>>>> One bugid should cover all of the jdk6 repositories. >>>>>> >>>>>> And I could push the changes in if need be, just say the word. >>>>>> >>>>>> -kto >>>>>> >>>>>> Mark Reinhold wrote: >>>>>>> >>>>>>> I've updated the jcheck extension to allow the unique-bugid >>>>>>> restriction to be disabled, and I've disabled that check in >>>>>>> the jdk6 forest. >>>>>>> >>>>>>> Joe: For the benefit of those using jcheck in their working >>>>>>> repos I suggest you update the .jcheck/conf file in each repo >>>>>>> to read: >>>>>>> >>>>>>> ? ?project=jdk6 >>>>>>> ? ?whitespace=lax >>>>>>> ? ?comments=lax >>>>>>> ? ?bugids=dup >>>>>>> >>>>>>> As for the extension itself, I'm working to get it published >>>>>>> externally, hopefully in the next week or two. >>>>>>> >>>>>>> - Mark >>>>> >>> >> > > http://mail.openjdk.java.net/pipermail/jdk6-dev/2009-September/000772.html > > Subject: hg: jdk6/jdk6/hotspot: 557 new changesets > > Woohoo! So do we move to hs16 after the next build (17) is promoted? ;) -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From John.Rose at Sun.COM Sat Sep 12 17:06:53 2009 From: John.Rose at Sun.COM (John Rose) Date: Sat, 12 Sep 2009 17:06:53 -0700 Subject: SA and disassemblers In-Reply-To: References: <147E5C84-EC8D-4628-82CE-33F815AE888D@sun.com> Message-ID: <63F66701-99CE-4A5B-9D5F-4F9DF49BCDF6@sun.com> On Sep 11, 2009, at 5:59 AM, Volker Simonis wrote: These are good ideas, Volker; thanks for thinking it all through. > I like the extension of the decode_instructions interface, especially > because this is something we are already using anyway. We have > extended the disassembler in the VM to decode instructions which had > been dumped by the VM earlier when no disassembler library was > available. We realized this with an 'AbstractDisassaembler' which in > our case is the base class of 'Disassembler'. If the native > disassembler can not be loaded, we automatically fall back to the > abstract disassembler which prints a kind of hex dump, but with all > the usual annotations. Later on, we can take such an output produced > by the abstract disassembler (for example from an hs_err file) and > decode it to real assembly code. Perhaps this is an extension you also > want to consider? I could contribute some code if you'd like. > > Besides this I have some remarks/suggestions regarding hsdis: > > - I don't really think it is necessary for hsdis.c to export two > functions: decode_instructions() and decode_instructions_virtual(). I > think the more general one decode_instructions_virtual() would be > enough together with a small change in disassembler.{cpp,hpp}: Moving forward, hsdis should keep compatibility with older VMs, so that a JVM developer can keep a recent version in the load library path, and still be able to work with multiple JVMs. This is, of course, less important for developers who work with only one JVM at a time. The implication is that hsdis should add new entry points that generalize the old ones. > address decode_env::decode_instructions(address start, address end, > address virtual_start /* = 0*/) { > if (virtual_start == 0) virtual_start = start; > > This would unify the hsdis interface used by the VM and the SA and > allow one to easily implement the decoding of "abstract disassembly" > as described above. Good point. In that way, decode_instructions_virtual extends decode_instructions. This reasoning takes the design back to Tom's original choice of name, something like decode_instructions_v2. > - in hsdis.c in hsdis_read_memory_func you use a C++ style comment > which I think should be better changed into a C style comment and > 'membar' should probably read 'mamaddr': (Yes.) > ... > + // convert the virtual address memaddr into an address within > memory buffer > + uintptr_t memaddr_p = ((uintptr_t) memaddr) - app_data->start_va + > app_data->start; > ... > > - The Readme file should contain the hint: > > "The binutils should be configured with the '--disable-nls' flag to > disable Native Language Support, otherwise you might get an "undefined > reference to `libintl_gettext'" if you try to load hsdis.so on systems > which don't have NLS by default." > > - There's a typo in the README file of the hsdis plugin: > line 70: 'hsdid-$LIBARCH.so' should read 'hsdis-$LIBARCH.so' > > - On IA64 and PPC, function pointers are pointers to function > descriptors, so hsdis-demo.c should be changed accordingly: > > static const char* lookup(void* addr) { > #if defined(__ia64) || defined(__powerpc__) > /* On IA64 and PPC function pointers are pointers to function > descriptors */ > #define CHECK_NAME(fn) \ > if (addr == *((void**) &fn)) return #fn; > #else > #define CHECK_NAME(fn) \ > if (addr == (void*) &fn) return #fn; > #endif Thanks! > ... > > void disassemble(void* from, void* to) { > #if defined(__ia64) || defined(__powerpc__) > /* On IA64 and PPC function pointers are pointers to function > descriptors */ > from = *((void**)from); > to = *((void**)to); > #endif > > - In the Makefile I need to link hsdis-demo against 'ld'. So I suggest > adding (at least for Linux): > > LDFLAGS += -ldl Yes. > - I don't understand why 'decode_instructions' in hsdis.c needs to > print a newline after every instruction. I think it would be more > consistent if this newline would be printed in the appropriate > callback in the disassembler class. I would therefore suggest to > delete the following lines from decode_instructions in hsdis.c: > > /* follow each complete insn by a nice newline */ > /*(*printf_callback)(printf_stream, "\n");*/ The output protocol for decode_insns is loosely structured text, a la XML (with no schema). In that format, newlines are about as good as any other delimiter. I suggest that if you want to translate up to a more structured output, just special-case a printf of a single newline. Remember that you get to specify that printf callback to be anything you want. I suppose the newlines could be enclosed by event pairs, but that seems like overkill to me. > - The previous change would also make it easier to use > decode_instructions() to decode a single instruction. But it would be > additionally necessary to change the line: > > while (p < end && !app_data.losing) { > > to: > > while (p <= end && !app_data.losing) { > > to make that possible. Additionally, "out of bound check" in > hsdis_read_memory_func() will have to be removed, if we want to decode > single instructions: > > if (memaddr_p + length > app_data->end) { > /* read is out of bounds */ > return EIO; > } else { > > I don't think that this does any harm, but on the other side it will > make the hsdis plugin more generally usable. That's a very good idea. Or, instead of having start==end be a magic condition, maybe we can have an optional argument which says "stop after emitting N instructions and return the updated pointer". > Finally I would like to suggest moving the printing of nmethods and > code blobs into the corresponding print methods of the CodeBlob and > nmethod classes.This could be easily achieved with the new > functionality which allows the decoding of a single assembler > instruction. I don't see a reason why the disassembler class needs to > know the internals of nmethod and CodeBlob. In my opinion it would be > a cleaner design if the disassembler class would export a clear > interface for decoding assembler instructions and leave all the rest > to the class like nmethod or CodeBlob which use it. That's a reasonable refactoring cleanup. We still need "raw" disassembly of ad hoc stubs, BTW. > Again this would > simplify the implementation of an "AbstractDisassembler" class as > described above because the code which prints all the various > annotations around the instructions would not have to be duplicated in > the "AbstractDisassembler" class. > > Thank you and best regards, > Volker > > > On 8/27/09, Tom Rodriguez wrote: >> One of the limitations of the current SA is that it doesn't have a >> disassembler for amd64 which makes looking at 64 bit cores somewhat >> challenging. Instead of trying to implement a full disassembler >> for x64 in >> Java I think we should switch the SA to using hsdis-arch for the >> decoding. >> It requires a minor extension to the decode_instructions interface >> so that >> we can disassemble a buffer of code that's not physically located >> where the >> code came from. I've got a working version of this that also fixes >> the >> printing to match up better with what the JVM itself prints. I was >> planning >> on blowing away the other disassemblers completely because they >> don't really >> fit into the new model. I thought I'd float this before finishing >> it to see >> if there are any concerns. The initial webrev is at >> http://cr.openjdk.java.net/~never/sadis. This includes >> building the SA with source 1.5 to allow use of printf which will >> probably >> be pushed separately. >> >> tom >> From John.Coomes at sun.com Sun Sep 13 12:46:24 2009 From: John.Coomes at sun.com (John Coomes) Date: Sun, 13 Sep 2009 12:46:24 -0700 Subject: PING 3: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <17c6771e0909120454m48172b3ao3c6b3e07a10ffa3f@mail.gmail.com> References: <17c6771e0909041021j10a046f0l5eec2e765bbe32e5@mail.gmail.com> <19105.21641.434524.306543@sun.com> <17c6771e0909041203x7b405e78pbc1586c3d26f5504@mail.gmail.com> <19105.63930.845263.728467@sun.com> <17c6771e0909060642y38631c09xf86f1121d938bb38@mail.gmail.com> <17c6771e0909070717k60d2be5cpce809698dc5aa0cb@mail.gmail.com> <19113.39846.175760.81942@sun.com> <17c6771e0909110907qd4b1b44wf43aa15fa8b729a5@mail.gmail.com> <19114.39417.509560.251572@sun.com> <17c6771e0909120454m48172b3ao3c6b3e07a10ffa3f@mail.gmail.com> Message-ID: <19117.19472.577113.644898@sun.com> Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: > 2009/9/11 John Coomes : > > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: ... > > Note that we (hotspot) use an auto-build system called jprt for all > > changes; it builds & tests on all platforms and does the push if > > everything is clean. ??If you create a changeset that jcheck will > > accept I'll submit it for you to jprt. ??Include me as a reviewer > > (jcoomes). > > > > You can publish the repo or generate a patch w/hg headers using 'hg > > export'. > > > ... > The exported patch is attached. It builds for me, so I hope all > finally goes well with the push :) After trying a windows build (successful), I submitted your patch to jprt, it will take a couple of hours. Administrivia: I imported the patch into a copy of the current hotspot-rt repo, effectively rebasing it; it applied cleanly. I also removed the Contributed-by: line from the comment since you have commit rights and the changeset lists you as the author. When to use the Contributed-by: line should be more clearly spelled out in the relevant part of the Developer's Guide[1]. I'll send a note to web-discuss about it. [1] http://openjdk.java.net/guide/producingChangeset.html -John From gnu_andrew at member.fsf.org Sun Sep 13 14:57:29 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sun, 13 Sep 2009 22:57:29 +0100 Subject: PING 3: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <19117.19472.577113.644898@sun.com> References: <17c6771e0909041021j10a046f0l5eec2e765bbe32e5@mail.gmail.com> <17c6771e0909041203x7b405e78pbc1586c3d26f5504@mail.gmail.com> <19105.63930.845263.728467@sun.com> <17c6771e0909060642y38631c09xf86f1121d938bb38@mail.gmail.com> <17c6771e0909070717k60d2be5cpce809698dc5aa0cb@mail.gmail.com> <19113.39846.175760.81942@sun.com> <17c6771e0909110907qd4b1b44wf43aa15fa8b729a5@mail.gmail.com> <19114.39417.509560.251572@sun.com> <17c6771e0909120454m48172b3ao3c6b3e07a10ffa3f@mail.gmail.com> <19117.19472.577113.644898@sun.com> Message-ID: <17c6771e0909131457n256e5fc0qbc1c1291b1a2f671@mail.gmail.com> 2009/9/13 John Coomes : > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: >> 2009/9/11 John Coomes : >> > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: > ... >> > Note that we (hotspot) use an auto-build system called jprt for all >> > changes; it builds & tests on all platforms and does the push if >> > everything is clean. ??If you create a changeset that jcheck will >> > accept I'll submit it for you to jprt. ??Include me as a reviewer >> > (jcoomes). >> > >> > You can publish the repo or generate a patch w/hg headers using 'hg >> > export'. >> > >> ... >> The exported patch is attached. ?It builds for me, so I hope all >> finally goes well with the push :) > > After trying a windows build (successful), I submitted your patch to > jprt, it will take a couple of hours. > Thanks. Good to finally get this in. > Administrivia: ?I imported the patch into a copy of the current > hotspot-rt repo, effectively rebasing it; it applied cleanly. ?I also > removed the Contributed-by: line from the comment since you have > commit rights and the changeset lists you as the author. ?When to use > the Contributed-by: line should be more clearly spelled out in the > relevant part of the Developer's Guide[1]. ?I'll send a note to > web-discuss about it. > I don't usually add it for my own patches for exactly the reasons you list, but wasn't sure what would happen with doing the commit via jprt. > [1] http://openjdk.java.net/guide/producingChangeset.html > > -John > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Sun Sep 13 23:38:40 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Sun, 13 Sep 2009 23:38:40 -0700 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <17c6771e0909120456l664ef0b8u8e25be6976b2763b@mail.gmail.com> References: <20090911162252.501B95B8@eggemoggin.niobe.net> <4AAA8847.4060409@sun.com> <4AAA8928.7030204@sun.com> <4AAA9126.2030308@sun.com> <4AAA9A63.2010200@sun.com> <4AAAA682.8060703@sun.com> <17c6771e0909120456l664ef0b8u8e25be6976b2763b@mail.gmail.com> Message-ID: <4AADE4F0.6040802@sun.com> Andrew John Hughes wrote: > 2009/9/11 Kelly O'Hair : > >> Push has finished. >> >> -kto >> >> Joseph D. Darcy wrote: >> >>> Thanks Kelly, >>> >>> -Joe >>> >>> Kelly O'Hair wrote: >>> >>>> Pushing now... or should I say >>>> ppppppuuuuuuusssssssshhhhhhhiiiiiinnnnnggggggg >>>> nnnnnnnnnooooooooooowwwwwwwwwww >>>> >>>> It's very slow. :^( >>>> >>>> Hopefully in the next 30mins... >>>> >>>> -kto >>>> >>>> Joseph D. Darcy wrote: >>>> >>>>> Kelly, >>>>> >>>>> Yes, please file a bug and push the changes; I approve these changes >>>>> going back. >>>>> >>>>> -Joe >>>>> >>>>> Kelly O'Hair wrote: >>>>> >>>>>> I think a bugid will be needed to push in the changesets that >>>>>> change the .jcheck/conf files in jdk6, shall I file one? >>>>>> One bugid should cover all of the jdk6 repositories. >>>>>> >>>>>> And I could push the changes in if need be, just say the word. >>>>>> >>>>>> -kto >>>>>> >>>>>> Mark Reinhold wrote: >>>>>> >>>>>>> I've updated the jcheck extension to allow the unique-bugid >>>>>>> restriction to be disabled, and I've disabled that check in >>>>>>> the jdk6 forest. >>>>>>> >>>>>>> Joe: For the benefit of those using jcheck in their working >>>>>>> repos I suggest you update the .jcheck/conf file in each repo >>>>>>> to read: >>>>>>> >>>>>>> project=jdk6 >>>>>>> whitespace=lax >>>>>>> comments=lax >>>>>>> bugids=dup >>>>>>> >>>>>>> As for the extension itself, I'm working to get it published >>>>>>> externally, hopefully in the next week or two. >>>>>>> >>>>>>> - Mark >>>>>>> > > http://mail.openjdk.java.net/pipermail/jdk6-dev/2009-September/000772.html > > Subject: hg: jdk6/jdk6/hotspot: 557 new changesets > > Woohoo! > Yay! Thanks, -Joe From Thomas.Rodriguez at Sun.COM Mon Sep 14 08:28:27 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 14 Sep 2009 08:28:27 -0700 Subject: SA and disassemblers In-Reply-To: References: <147E5C84-EC8D-4628-82CE-33F815AE888D@sun.com> Message-ID: <4A566258-CCFF-4ED9-B75B-E3970BB90A22@Sun.COM> On Sep 11, 2009, at 5:59 AM, Volker Simonis wrote: > Hi Tom, > > I like the extension of the decode_instructions interface, especially > because this is something we are already using anyway. We have > extended the disassembler in the VM to decode instructions which had > been dumped by the VM earlier when no disassembler library was > available. We realized this with an 'AbstractDisassaembler' which in > our case is the base class of 'Disassembler'. If the native > disassembler can not be loaded, we automatically fall back to the > abstract disassembler which prints a kind of hex dump, but with all > the usual annotations. Later on, we can take such an output produced > by the abstract disassembler (for example from an hs_err file) and > decode it to real assembly code. Perhaps this is an extension you also > want to consider? I could contribute some code if you'd like. That's interesting. We have a separate tool that we use like this for decoding the disassembly in an hs_err. It's different than our hsdis library since it allows disassembly any supported CPU on any supported CPU, so we can process an x86 hs_err on sparc or vice versa. If you are motivated to contribute your changes they sound interesting so send them out. > > Besides this I have some remarks/suggestions regarding hsdis: > > - I don't really think it is necessary for hsdis.c to export two > functions: decode_instructions() and decode_instructions_virtual(). I > think the more general one decode_instructions_virtual() would be > enough together with a small change in disassembler.{cpp,hpp}: I'd updated disassembler.cpp to use the new interface but I want to maintain the old interface so the hsdis library itself will continue to work with old JVMs. > > address decode_env::decode_instructions(address start, address end, > address virtual_start /* = 0*/) { > if (virtual_start == 0) virtual_start = start; > > This would unify the hsdis interface used by the VM and the SA and > allow one to easily implement the decoding of "abstract disassembly" > as described above. I wasn't planning on exposing that argument outside of disassembler.cpp but there's no reason it couldn't be later if it's useful. > > - in hsdis.c in hsdis_read_memory_func you use a C++ style comment > which I think should be better changed into a C style comment and > 'membar' should probably read 'mamaddr': Agreed. I also fixed a few other instances of // style comments in that file. > ... > > - The Readme file should contain the hint: > > "The binutils should be configured with the '--disable-nls' flag to > disable Native Language Support, otherwise you might get an "undefined > reference to `libintl_gettext'" if you try to load hsdis.so on systems > which don't have NLS by default." It's used automatically in the makefile when it configures binutils but it's true there's no explanation of why. I added this comment: Binutils should be configured with the '--disable-nls' flag to disable Native Language Support, otherwise you might get an "undefined reference to `libintl_gettext'" if you try to load hsdis.so on systems which don't have NLS by default. It also avoids build problems on other configurations that don't include the full NLS support. > > - There's a typo in the README file of the hsdis plugin: > line 70: 'hsdid-$LIBARCH.so' should read 'hsdis-$LIBARCH.so' I don't see this. The only reference I see in the README is as you say. > > - On IA64 and PPC, function pointers are pointers to function > descriptors, so hsdis-demo.c should be changed accordingly: I've added those. > - In the Makefile I need to link hsdis-demo against 'ld'. So I suggest > adding (at least for Linux): > > LDFLAGS += -ldl The current Makefile already includes that. I think you are looking at an old version of these files. I updated hsdis quite a bit in http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/67a2f5ba5582 and fixed the hsdid typo, the binutils setup and the ldflags. It should just work out of the box as of that version. > > - I don't understand why 'decode_instructions' in hsdis.c needs to > print a newline after every instruction. I think it would be more > consistent if this newline would be printed in the appropriate > callback in the disassembler class. I would therefore suggest to > delete the following lines from decode_instructions in hsdis.c: > > /* follow each complete insn by a nice newline */ > /*(*printf_callback)(printf_stream, "\n");*/ I agree is seems like the wrong place to do that for an disassembly API. I could make it default to not printing the newline when called as decode_instructions_virtual but keep the old behaviour for compatibility. What do you think? > > > - The previous change would also make it easier to use > decode_instructions() to decode a single instruction. But it would be > additionally necessary to change the line: > > while (p < end && !app_data.losing) { > > to: > > while (p <= end && !app_data.losing) { > > to make that possible. Additionally, "out of bound check" in > hsdis_read_memory_func() will have to be removed, if we want to decode > single instructions: > > if (memaddr_p + length > app_data->end) { > /* read is out of bounds */ > return EIO; > } else { > > I don't think that this does any harm, but on the other side it will > make the hsdis plugin more generally usable. Except that you could crash by reading further than was actually provided. Alternatively we could add end_va to decode_instructions_virtual to make it complete. How about this for the signature? void* decode_instructions_virtual(uintptr_t start_va, uintptr_t end_va, unsigned char* buffer, int length, void* (*event_callback)(void*, const char*, void*), void* event_stream, int (*printf_callback)(void*, const char*, ...), void* printf_stream, const char* options); > > Finally I would like to suggest moving the printing of nmethods and > code blobs into the corresponding print methods of the CodeBlob and > nmethod classes.This could be easily achieved with the new > functionality which allows the decoding of a single assembler > instruction. I don't see a reason why the disassembler class needs to > know the internals of nmethod and CodeBlob. In my opinion it would be > a cleaner design if the disassembler class would export a clear > interface for decoding assembler instructions and leave all the rest > to the class like nmethod or CodeBlob which use it. Again this would > simplify the implementation of an "AbstractDisassembler" class as > described above because the code which prints all the various > annotations around the instructions would not have to be duplicated in > the "AbstractDisassembler" class. I'm not against that but I'm don't want to tackle that as part of this change. Thanks for you feedback. tom > > Thank you and best regards, > Volker > > > On 8/27/09, Tom Rodriguez wrote: >> One of the limitations of the current SA is that it doesn't have a >> disassembler for amd64 which makes looking at 64 bit cores somewhat >> challenging. Instead of trying to implement a full disassembler >> for x64 in >> Java I think we should switch the SA to using hsdis-arch for the >> decoding. >> It requires a minor extension to the decode_instructions interface >> so that >> we can disassemble a buffer of code that's not physically located >> where the >> code came from. I've got a working version of this that also fixes >> the >> printing to match up better with what the JVM itself prints. I was >> planning >> on blowing away the other disassemblers completely because they >> don't really >> fit into the new model. I thought I'd float this before finishing >> it to see >> if there are any concerns. The initial webrev is at >> http://cr.openjdk.java.net/~never/sadis. This includes >> building the SA with source 1.5 to allow use of printf which will >> probably >> be pushed separately. >> >> tom >> From vladimir.kozlov at sun.com Mon Sep 14 16:10:39 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Mon, 14 Sep 2009 23:10:39 +0000 Subject: hg: jdk7/hotspot/hotspot: 11 new changesets Message-ID: <20090914231105.7868B1218E@hg.openjdk.java.net> Changeset: 489a4f8dcd0f Author: twisti Date: 2009-08-27 06:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/489a4f8dcd0f 6865583: Verbose CIPrintMethodCodes asserts when ldc an empty String Summary: ldc seems to load an empty String and that leads to an assert on offset < length, which are both zero. Reviewed-by: kvn, never ! src/share/vm/classfile/javaClasses.cpp Changeset: 8fe1963e3964 Author: kvn Date: 2009-08-28 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8fe1963e3964 6875577: CTW fails with /hotspot/src/share/vm/opto/memnode.cpp Summary: Fix do_null_check to check for unloaded klass for all oop pointers. Reviewed-by: never, cfang ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp Changeset: 1fbd5d696bf4 Author: twisti Date: 2009-08-31 02:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1fbd5d696bf4 6875967: CTW fails with./generated/adfiles/ad_sparc.cpp:6711 Reviewed-by: cfang, never ! src/cpu/sparc/vm/sparc.ad Changeset: ace8397c8563 Author: cfang Date: 2009-08-31 08:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ace8397c8563 6876276: assert(!is_visited,"visit only once") Summary: schedule the superword loads based on dependence constraints Reviewed-by: kvn, never ! src/share/vm/opto/superword.cpp ! test/compiler/6636138/Test1.java ! test/compiler/6636138/Test2.java Changeset: ff1a29907b6c Author: never Date: 2009-08-31 17:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ff1a29907b6c 6855215: Calculation error (NaN) after about 1500 calculations Reviewed-by: kvn ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp + test/compiler/6855215/Test6855215.java Changeset: 0f1c19b7a52d Author: kvn Date: 2009-09-08 10:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0f1c19b7a52d 6875619: CTW fails with /hotspot/src/share/vm/opto/type.hpp Summary: In load_array_length() cast array's type to TypeOopPtr when calling make_ideal_length() method. Reviewed-by: never ! src/share/vm/opto/graphKit.cpp Changeset: 26fbe81d30cf Author: kvn Date: 2009-09-08 16:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/26fbe81d30cf 6880052: SIGSEGV in GraphKit::null_check_common() Summary: Check that a klass is not NULL before the is_loaded() call. Reviewed-by: never ! src/share/vm/opto/graphKit.cpp Changeset: 9a4e87ba1a90 Author: kvn Date: 2009-09-09 16:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9a4e87ba1a90 6880533: test/compiler/6865031/Test.java miss -XX:+IgnoreUnrecognizedVMOptions Summary: Add missing test option -XX:+IgnoreUnrecognizedVMOptions. Reviewed-by: never ! test/compiler/6865031/Test.java Changeset: 159d56b94894 Author: kvn Date: 2009-09-10 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/159d56b94894 6880574: C2 assert in escape.cpp:445 on linux-amd64 Summary: Look through chained AddP nodes in get_addp_base(). Reviewed-by: jrose ! src/share/vm/opto/escape.cpp Changeset: c7e94e8fff43 Author: kvn Date: 2009-09-10 18:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c7e94e8fff43 6880053: assert(alloc_obj->as_CheckCastPP()->type() != TypeInstPtr::NOTNULL) Summary: Removed second CheckCastPP and use MembarCPUOrder after arraycopy to cloned object. Reviewed-by: never ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: a6f533fc33e0 Author: kvn Date: 2009-09-14 11:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a6f533fc33e0 Merge From Daniel.Daugherty at Sun.COM Tue Sep 15 08:30:38 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Tue, 15 Sep 2009 09:30:38 -0600 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <17c6771e0909120457u7bbfb444h39d69c57630a143e@mail.gmail.com> References: <20090911162252.501B95B8@eggemoggin.niobe.net> <4AAA8847.4060409@sun.com> <4AAA8928.7030204@sun.com> <4AAA9126.2030308@sun.com> <4AAA9A63.2010200@sun.com> <4AAAA682.8060703@sun.com> <17c6771e0909120456l664ef0b8u8e25be6976b2763b@mail.gmail.com> <17c6771e0909120457u7bbfb444h39d69c57630a143e@mail.gmail.com> Message-ID: <4AAFB31E.4080608@sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090915/4fe17446/attachment.html From Kelly.Ohair at Sun.COM Tue Sep 15 09:01:46 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 15 Sep 2009 09:01:46 -0700 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <4AAFB31E.4080608@sun.com> References: <20090911162252.501B95B8@eggemoggin.niobe.net> <4AAA8847.4060409@sun.com> <4AAA8928.7030204@sun.com> <4AAA9126.2030308@sun.com> <4AAA9A63.2010200@sun.com> <4AAAA682.8060703@sun.com> <17c6771e0909120456l664ef0b8u8e25be6976b2763b@mail.gmail.com> <17c6771e0909120457u7bbfb444h39d69c57630a143e@mail.gmail.com> <4AAFB31E.4080608@sun.com> Message-ID: <4AAFBA6A.4060807@sun.com> They look fine, so you can use me as a reviewer, if needed. I always do a double check with Joe Darcy, just to make sure I don't mess up any potential openjdk6 build promotion activities and to make sure the fix is wanted in openjdk6. These changes are needed and wanted, in my opinion. -kto Daniel D. Daugherty wrote: > Andrew John Hughes wrote: >> 2009/9/12 Andrew John Hughes : >> >>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2009-September/000772.html >>> >>> Subject: hg: jdk6/jdk6/hotspot: 557 new changesets >>> >>> Woohoo! >>> >> >> So do we move to hs16 after the next build (17) is promoted? ;) >> > > Now that OpenJDK6 is caught up to HSX-14, I have two critical > bug fixes ready: > > % hg out > comparing with ssh://hg.openjdk.java.net/jdk6/jdk6/hotspot > searching for changes > changeset: 616:2b4230d1e589 > parent: 559:26bc4770e671 > user: dcubed > date: Tue Jul 28 13:35:00 2009 -0600 > summary: 6862295: JDWP threadid changes during debugging session > (leading to ingored breakpoints) > > changeset: 617:9601152ccfc1 > user: dcubed > date: Fri Aug 28 12:25:46 2009 -0600 > summary: 6875393: 2/3 JNI itable index cache is broken > > changeset: 618:16a50381378e > tag: tip > parent: 615:ccb185a165a1 > parent: 617:9601152ccfc1 > user: dcubed > date: Tue Sep 15 09:15:51 2009 -0600 > summary: Merge > > > The first changeset is in 6u16-B01/HSX-14.2-B01 and JDK7-B71/HSX-16-B08. > The second changeset is in 6u18-B02/HSX-16-B09 and HSX-17-B02; the second > changeset hasn't made it from RT_Baseline into Main_Baseline yet. :-( > > http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2b4230d1e589 > > http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/9601152ccfc1 > > So how do I get approval for pushing these fixes to OpenJDK6? > > Dan > > From Daniel.Daugherty at Sun.COM Tue Sep 15 09:13:47 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Tue, 15 Sep 2009 10:13:47 -0600 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <4AAFBA6A.4060807@sun.com> References: <20090911162252.501B95B8@eggemoggin.niobe.net> <4AAA8847.4060409@sun.com> <4AAA8928.7030204@sun.com> <4AAA9126.2030308@sun.com> <4AAA9A63.2010200@sun.com> <4AAAA682.8060703@sun.com> <17c6771e0909120456l664ef0b8u8e25be6976b2763b@mail.gmail.com> <17c6771e0909120457u7bbfb444h39d69c57630a143e@mail.gmail.com> <4AAFB31E.4080608@sun.com> <4AAFBA6A.4060807@sun.com> Message-ID: <4AAFBD3B.5010205@sun.com> Thanks Kelly! The changes were already reviewed. I'll wait to hear from Joe Darcy... Dan Kelly O'Hair wrote: > They look fine, so you can use me as a reviewer, if needed. > > I always do a double check with Joe Darcy, just to make sure > I don't mess up any potential openjdk6 build promotion activities > and to make sure the fix is wanted in openjdk6. > > These changes are needed and wanted, in my opinion. > > -kto > > > Daniel D. Daugherty wrote: >> Andrew John Hughes wrote: >>> 2009/9/12 Andrew John Hughes : >>> >>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2009-September/000772.html >>>> >>>> >>>> Subject: hg: jdk6/jdk6/hotspot: 557 new changesets >>>> >>>> Woohoo! >>>> >>> >>> So do we move to hs16 after the next build (17) is promoted? ;) >>> >> >> Now that OpenJDK6 is caught up to HSX-14, I have two critical >> bug fixes ready: >> >> % hg out >> comparing with ssh://hg.openjdk.java.net/jdk6/jdk6/hotspot >> searching for changes >> changeset: 616:2b4230d1e589 >> parent: 559:26bc4770e671 >> user: dcubed >> date: Tue Jul 28 13:35:00 2009 -0600 >> summary: 6862295: JDWP threadid changes during debugging session >> (leading to ingored breakpoints) >> >> changeset: 617:9601152ccfc1 >> user: dcubed >> date: Fri Aug 28 12:25:46 2009 -0600 >> summary: 6875393: 2/3 JNI itable index cache is broken >> >> changeset: 618:16a50381378e >> tag: tip >> parent: 615:ccb185a165a1 >> parent: 617:9601152ccfc1 >> user: dcubed >> date: Tue Sep 15 09:15:51 2009 -0600 >> summary: Merge >> >> >> The first changeset is in 6u16-B01/HSX-14.2-B01 and JDK7-B71/HSX-16-B08. >> The second changeset is in 6u18-B02/HSX-16-B09 and HSX-17-B02; the >> second >> changeset hasn't made it from RT_Baseline into Main_Baseline yet. :-( >> >> http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2b4230d1e589 >> >> http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/9601152ccfc1 >> >> So how do I get approval for pushing these fixes to OpenJDK6? >> >> Dan >> >> From gnu_andrew at member.fsf.org Tue Sep 15 09:19:04 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 15 Sep 2009 17:19:04 +0100 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <4AAFB31E.4080608@sun.com> References: <20090911162252.501B95B8@eggemoggin.niobe.net> <4AAA8847.4060409@sun.com> <4AAA8928.7030204@sun.com> <4AAA9126.2030308@sun.com> <4AAA9A63.2010200@sun.com> <4AAAA682.8060703@sun.com> <17c6771e0909120456l664ef0b8u8e25be6976b2763b@mail.gmail.com> <17c6771e0909120457u7bbfb444h39d69c57630a143e@mail.gmail.com> <4AAFB31E.4080608@sun.com> Message-ID: <17c6771e0909150919n257cc777jc017bdfb729fae79@mail.gmail.com> 2009/9/15 Daniel D. Daugherty : > Andrew John Hughes wrote: > > 2009/9/12 Andrew John Hughes : > > > http://mail.openjdk.java.net/pipermail/jdk6-dev/2009-September/000772.html > > Subject: hg: jdk6/jdk6/hotspot: 557 new changesets > > Woohoo! > > > So do we move to hs16 after the next build (17) is promoted? ;) > > > Now that OpenJDK6 is caught up to HSX-14, I have two critical > bug fixes ready: > > % hg out > comparing with ssh://hg.openjdk.java.net/jdk6/jdk6/hotspot > searching for changes > changeset:?? 616:2b4230d1e589 > parent:????? 559:26bc4770e671 > user:??????? dcubed > date:??????? Tue Jul 28 13:35:00 2009 -0600 > summary:???? 6862295: JDWP threadid changes during debugging session > (leading to ingored breakpoints) > > changeset:?? 617:9601152ccfc1 > user:??????? dcubed > date:??????? Fri Aug 28 12:25:46 2009 -0600 > summary:???? 6875393: 2/3 JNI itable index cache is broken > > changeset:?? 618:16a50381378e > tag:???????? tip > parent:????? 615:ccb185a165a1 > parent:????? 617:9601152ccfc1 > user:??????? dcubed > date:??????? Tue Sep 15 09:15:51 2009 -0600 > summary:???? Merge > > > The first changeset is in 6u16-B01/HSX-14.2-B01 and JDK7-B71/HSX-16-B08. I'm confused; if this is in hs14, why do we not have it already? > The second changeset is in 6u18-B02/HSX-16-B09 and HSX-17-B02; the second > changeset hasn't made it from RT_Baseline into Main_Baseline yet. :-( > > http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2b4230d1e589 > > http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/9601152ccfc1 > > So how do I get approval for pushing these fixes to OpenJDK6? > > Dan > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Daniel.Daugherty at Sun.COM Tue Sep 15 09:45:51 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Tue, 15 Sep 2009 10:45:51 -0600 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <17c6771e0909150919n257cc777jc017bdfb729fae79@mail.gmail.com> References: <20090911162252.501B95B8@eggemoggin.niobe.net> <4AAA8847.4060409@sun.com> <4AAA8928.7030204@sun.com> <4AAA9126.2030308@sun.com> <4AAA9A63.2010200@sun.com> <4AAAA682.8060703@sun.com> <17c6771e0909120456l664ef0b8u8e25be6976b2763b@mail.gmail.com> <17c6771e0909120457u7bbfb444h39d69c57630a143e@mail.gmail.com> <4AAFB31E.4080608@sun.com> <17c6771e0909150919n257cc777jc017bdfb729fae79@mail.gmail.com> Message-ID: <4AAFC4BF.7040801@sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090915/6342138d/attachment.html From Joe.Darcy at Sun.COM Tue Sep 15 11:22:40 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 15 Sep 2009 11:22:40 -0700 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <4AAFBD3B.5010205@sun.com> References: <20090911162252.501B95B8@eggemoggin.niobe.net> <4AAA8847.4060409@sun.com> <4AAA8928.7030204@sun.com> <4AAA9126.2030308@sun.com> <4AAA9A63.2010200@sun.com> <4AAAA682.8060703@sun.com> <17c6771e0909120456l664ef0b8u8e25be6976b2763b@mail.gmail.com> <17c6771e0909120457u7bbfb444h39d69c57630a143e@mail.gmail.com> <4AAFB31E.4080608@sun.com> <4AAFBA6A.4060807@sun.com> <4AAFBD3B.5010205@sun.com> Message-ID: <4AAFDB70.7020307@sun.com> Hi Dan. Please push these fixes. Thanks, -Joe Daniel D. Daugherty wrote: > Thanks Kelly! The changes were already reviewed. I'll wait to > hear from Joe Darcy... > > Dan > > > Kelly O'Hair wrote: >> They look fine, so you can use me as a reviewer, if needed. >> >> I always do a double check with Joe Darcy, just to make sure >> I don't mess up any potential openjdk6 build promotion activities >> and to make sure the fix is wanted in openjdk6. >> >> These changes are needed and wanted, in my opinion. >> >> -kto >> >> >> Daniel D. Daugherty wrote: >>> Andrew John Hughes wrote: >>>> 2009/9/12 Andrew John Hughes : >>>> >>>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2009-September/000772.html >>>>> >>>>> >>>>> Subject: hg: jdk6/jdk6/hotspot: 557 new changesets >>>>> >>>>> Woohoo! >>>>> >>>> >>>> So do we move to hs16 after the next build (17) is promoted? ;) >>>> >>> >>> Now that OpenJDK6 is caught up to HSX-14, I have two critical >>> bug fixes ready: >>> >>> % hg out >>> comparing with ssh://hg.openjdk.java.net/jdk6/jdk6/hotspot >>> searching for changes >>> changeset: 616:2b4230d1e589 >>> parent: 559:26bc4770e671 >>> user: dcubed >>> date: Tue Jul 28 13:35:00 2009 -0600 >>> summary: 6862295: JDWP threadid changes during debugging session >>> (leading to ingored breakpoints) >>> >>> changeset: 617:9601152ccfc1 >>> user: dcubed >>> date: Fri Aug 28 12:25:46 2009 -0600 >>> summary: 6875393: 2/3 JNI itable index cache is broken >>> >>> changeset: 618:16a50381378e >>> tag: tip >>> parent: 615:ccb185a165a1 >>> parent: 617:9601152ccfc1 >>> user: dcubed >>> date: Tue Sep 15 09:15:51 2009 -0600 >>> summary: Merge >>> >>> >>> The first changeset is in 6u16-B01/HSX-14.2-B01 and >>> JDK7-B71/HSX-16-B08. >>> The second changeset is in 6u18-B02/HSX-16-B09 and HSX-17-B02; the >>> second >>> changeset hasn't made it from RT_Baseline into Main_Baseline yet. :-( >>> >>> http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2b4230d1e589 >>> >>> http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/9601152ccfc1 >>> >>> So how do I get approval for pushing these fixes to OpenJDK6? >>> >>> Dan >>> >>> From Daniel.Daugherty at Sun.COM Tue Sep 15 12:19:16 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Tue, 15 Sep 2009 13:19:16 -0600 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <4AAFDB70.7020307@sun.com> References: <20090911162252.501B95B8@eggemoggin.niobe.net> <4AAA8847.4060409@sun.com> <4AAA8928.7030204@sun.com> <4AAA9126.2030308@sun.com> <4AAA9A63.2010200@sun.com> <4AAAA682.8060703@sun.com> <17c6771e0909120456l664ef0b8u8e25be6976b2763b@mail.gmail.com> <17c6771e0909120457u7bbfb444h39d69c57630a143e@mail.gmail.com> <4AAFB31E.4080608@sun.com> <4AAFBA6A.4060807@sun.com> <4AAFBD3B.5010205@sun.com> <4AAFDB70.7020307@sun.com> Message-ID: <4AAFE8B4.80000@sun.com> Done. BTW, how do I get on the notification list for this repo? Dan Joseph D. Darcy wrote: > Hi Dan. > > Please push these fixes. > > Thanks, > > -Joe > > Daniel D. Daugherty wrote: >> Thanks Kelly! The changes were already reviewed. I'll wait to >> hear from Joe Darcy... >> >> Dan >> >> >> Kelly O'Hair wrote: >>> They look fine, so you can use me as a reviewer, if needed. >>> >>> I always do a double check with Joe Darcy, just to make sure >>> I don't mess up any potential openjdk6 build promotion activities >>> and to make sure the fix is wanted in openjdk6. >>> >>> These changes are needed and wanted, in my opinion. >>> >>> -kto >>> >>> >>> Daniel D. Daugherty wrote: >>>> Andrew John Hughes wrote: >>>>> 2009/9/12 Andrew John Hughes : >>>>> >>>>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2009-September/000772.html >>>>>> >>>>>> >>>>>> Subject: hg: jdk6/jdk6/hotspot: 557 new changesets >>>>>> >>>>>> Woohoo! >>>>>> >>>>> >>>>> So do we move to hs16 after the next build (17) is promoted? ;) >>>>> >>>> >>>> Now that OpenJDK6 is caught up to HSX-14, I have two critical >>>> bug fixes ready: >>>> >>>> % hg out >>>> comparing with ssh://hg.openjdk.java.net/jdk6/jdk6/hotspot >>>> searching for changes >>>> changeset: 616:2b4230d1e589 >>>> parent: 559:26bc4770e671 >>>> user: dcubed >>>> date: Tue Jul 28 13:35:00 2009 -0600 >>>> summary: 6862295: JDWP threadid changes during debugging >>>> session (leading to ingored breakpoints) >>>> >>>> changeset: 617:9601152ccfc1 >>>> user: dcubed >>>> date: Fri Aug 28 12:25:46 2009 -0600 >>>> summary: 6875393: 2/3 JNI itable index cache is broken >>>> >>>> changeset: 618:16a50381378e >>>> tag: tip >>>> parent: 615:ccb185a165a1 >>>> parent: 617:9601152ccfc1 >>>> user: dcubed >>>> date: Tue Sep 15 09:15:51 2009 -0600 >>>> summary: Merge >>>> >>>> >>>> The first changeset is in 6u16-B01/HSX-14.2-B01 and >>>> JDK7-B71/HSX-16-B08. >>>> The second changeset is in 6u18-B02/HSX-16-B09 and HSX-17-B02; the >>>> second >>>> changeset hasn't made it from RT_Baseline into Main_Baseline yet. :-( >>>> >>>> http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2b4230d1e589 >>>> >>>> http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/9601152ccfc1 >>>> >>>> So how do I get approval for pushing these fixes to OpenJDK6? >>>> >>>> Dan >>>> >>>> > From Tim.Bell at Sun.COM Tue Sep 15 12:28:38 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Tue, 15 Sep 2009 12:28:38 -0700 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <4AAFE8B4.80000@sun.com> References: <20090911162252.501B95B8@eggemoggin.niobe.net> <4AAA8847.4060409@sun.com> <4AAA8928.7030204@sun.com> <4AAA9126.2030308@sun.com> <4AAA9A63.2010200@sun.com> <4AAAA682.8060703@sun.com> <17c6771e0909120456l664ef0b8u8e25be6976b2763b@mail.gmail.com> <17c6771e0909120457u7bbfb444h39d69c57630a143e@mail.gmail.com> <4AAFB31E.4080608@sun.com> <4AAFBA6A.4060807@sun.com> <4AAFBD3B.5010205@sun.com> <4AAFDB70.7020307@sun.com> <4AAFE8B4.80000@sun.com> Message-ID: <4AAFEAE6.90200@sun.com> Hi Dan: > Done. > > BTW, how do I get on the notification list for this repo? OpenJDK6 changes go to jdk6-dev at openjdk.java.net (see below). To subscribe, visit this page: http://mail.openjdk.java.net/mailman/listinfo/jdk6-dev Tim -------- Original Message -------- Subject: hg: jdk6/jdk6/hotspot: 4 new changesets Date: Tue, 15 Sep 2009 19:12:09 +0000 From: Daniel.Daugherty at Sun.COM To: jdk6-dev at openjdk.java.net Changeset: 2b4230d1e589 Author: dcubed Date: 2009-07-28 13:35 -0600 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/2b4230d1e589 6862295: JDWP threadid changes during debugging session (leading to ingored breakpoints) Summary: Correctly count full GC operations for framework collectors. Add ForceFullGCJVMTIEpilogues as a future work around if needed. Reviewed-by: jcoomes, alanb, ysr ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/globals.hpp Changeset: 9601152ccfc1 Author: dcubed Date: 2009-08-28 12:25 -0600 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/9601152ccfc1 6875393: 2/3 JNI itable index cache is broken Summary: Add missing initialization of cache size. Reviewed-by: tbell ! src/share/vm/oops/instanceKlass.cpp Changeset: 16a50381378e Author: dcubed Date: 2009-09-15 09:15 -0600 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/16a50381378e Merge ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/globals.hpp Changeset: ae86d1ece6f5 Author: dcubed Date: 2009-09-15 13:15 -0600 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/ae86d1ece6f5 Merge From gnu_andrew at member.fsf.org Tue Sep 15 13:50:02 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 15 Sep 2009 21:50:02 +0100 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <4AAFC4BF.7040801@sun.com> References: <20090911162252.501B95B8@eggemoggin.niobe.net> <4AAA8928.7030204@sun.com> <4AAA9126.2030308@sun.com> <4AAA9A63.2010200@sun.com> <4AAAA682.8060703@sun.com> <17c6771e0909120456l664ef0b8u8e25be6976b2763b@mail.gmail.com> <17c6771e0909120457u7bbfb444h39d69c57630a143e@mail.gmail.com> <4AAFB31E.4080608@sun.com> <17c6771e0909150919n257cc777jc017bdfb729fae79@mail.gmail.com> <4AAFC4BF.7040801@sun.com> Message-ID: <17c6771e0909151350o3d46e4c0jaa97d75e94a50a8d@mail.gmail.com> 2009/9/15 Daniel D. Daugherty : > Andrew John Hughes wrote: > > 2009/9/15 Daniel D. Daugherty : > > > The first changeset is in 6u16-B01/HSX-14.2-B01 and JDK7-B71/HSX-16-B08. > > > I'm confused; if this is in hs14, why do we not have it already? > > > The fix for 6862295 is in HSX-14.2 which is a fork created just for > 6u16. OpenJDK6 currently contains HSX-14 (not sure which build)... > Ok, I thought the whole point of http://hg.openjdk.java.net/hsx/hs14/master was so that we *didn't* have these proprietary forks. OpenJDK6 now matches the current tip of hs14/master (or did on Saturday). > You might remember my asking questions about pushing this fix back > when OpenJDK6 was based on HSX-12... and I couldn't get there from > here... :-) > I do, there wasn't too much point in doing it then and it was good to see you repost so quickly after the merge. Thanks for bringing over these patches. I just wish others were as conscientious towards OpenJDK6. > Dan > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Daniel.Daugherty at Sun.COM Tue Sep 15 14:50:14 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Tue, 15 Sep 2009 15:50:14 -0600 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <17c6771e0909151350o3d46e4c0jaa97d75e94a50a8d@mail.gmail.com> References: <20090911162252.501B95B8@eggemoggin.niobe.net> <4AAA8928.7030204@sun.com> <4AAA9126.2030308@sun.com> <4AAA9A63.2010200@sun.com> <4AAAA682.8060703@sun.com> <17c6771e0909120456l664ef0b8u8e25be6976b2763b@mail.gmail.com> <17c6771e0909120457u7bbfb444h39d69c57630a143e@mail.gmail.com> <4AAFB31E.4080608@sun.com> <17c6771e0909150919n257cc777jc017bdfb729fae79@mail.gmail.com> <4AAFC4BF.7040801@sun.com> <17c6771e0909151350o3d46e4c0jaa97d75e94a50a8d@mail.gmail.com> Message-ID: <4AB00C16.4050606@sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090915/dee0afd2/attachment.html From gnu_andrew at member.fsf.org Tue Sep 15 16:09:35 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 16 Sep 2009 00:09:35 +0100 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <4AB00C16.4050606@sun.com> References: <20090911162252.501B95B8@eggemoggin.niobe.net> <4AAA9A63.2010200@sun.com> <4AAAA682.8060703@sun.com> <17c6771e0909120456l664ef0b8u8e25be6976b2763b@mail.gmail.com> <17c6771e0909120457u7bbfb444h39d69c57630a143e@mail.gmail.com> <4AAFB31E.4080608@sun.com> <17c6771e0909150919n257cc777jc017bdfb729fae79@mail.gmail.com> <4AAFC4BF.7040801@sun.com> <17c6771e0909151350o3d46e4c0jaa97d75e94a50a8d@mail.gmail.com> <4AB00C16.4050606@sun.com> Message-ID: <17c6771e0909151609u21ef624fha54c39df7f8d9051@mail.gmail.com> 2009/9/15 Daniel D. Daugherty : > Andrew John Hughes wrote: > > 2009/9/15 Daniel D. Daugherty : > > > Andrew John Hughes wrote: > > 2009/9/15 Daniel D. Daugherty : > > > The first changeset is in 6u16-B01/HSX-14.2-B01 and JDK7-B71/HSX-16-B08. > > > I'm confused; if this is in hs14, why do we not have it already? > > > The fix for 6862295 is in HSX-14.2 which is a fork created just for > 6u16. OpenJDK6 currently contains HSX-14 (not sure which build)... > > > > Ok, I thought the whole point of > http://hg.openjdk.java.net/hsx/hs14/master was so that we *didn't* > have these proprietary forks. > > I don't know why HSX-14.2 was created. I just know that was where > I was told to push the fix so that it could get out the door as > soon as possible. There was talk about holding up 6u15 but since > that was a security release it couldn't wait a week. So the fix > went into 6u16... > Sorry if it sounded like I was blaming you personally, because that certainly wasn't the intention. I'm just still very confused as to why we have this hs14 tree (and I assume the same applies to hs16 too) operating in a manner where externals aren't allowed to commit to it and where Sun don't always do so either. > > OpenJDK6 now matches the current tip of > hs14/master (or did on Saturday). > > > I didn't push anything to hs14/master... Maybe this is something > that Erik does... > The last commit was four months ago it seems. I assume work on a stable HotSpot has now switched to hs16. I'd like OpenJDK6 to switch to that too after b17, but Joe hasn't responded on that yet. > > You might remember my asking questions about pushing this fix back > when OpenJDK6 was based on HSX-12... and I couldn't get there from > here... :-) > > > > I do, there wasn't too much point in doing it then and it was good to > see you repost so quickly after the merge. > > I've been watching and waiting for the administrivia to > get worked out on the OpenJDK6 stuff... :-) > > > Thanks for bringing over these patches. > > Not a problem. It seemed to me that OpenJDK6 really needed breakpoints > that work :-)? And the other fix was just a 1-liner that fixed malloc > pool corruption in the regular (non-debugging, non-profiling) system > so it seemed important at the time... :-) > > > I just wish others were as conscientious towards OpenJDK6. > > > I'd say that Joe was beating on me, but I don't make it out to CA > very often anymore and I haven't seen him in CO so... :-) > Oh yeah, I thought Joe's work was implied, him being OpenJDK6 maintainer and all :) What we don't generally see is those working on something for OpenJDK7 thinking 'hey, this fixes a bug/regression that would be good to have in OpenJDK6 too'. Instead, I'd say pretty much all the backports come from either us at Red Hat or Google and that's pretty much when we spot something useful going by on the JDK7 lists. > Dan > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From eric.v at upcmail.nl Wed Sep 16 08:27:20 2009 From: eric.v at upcmail.nl (ericjoh) Date: Wed, 16 Sep 2009 08:27:20 -0700 (PDT) Subject: gdb java Message-ID: <25474813.post@talk.nabble.com> Hi, I build the JDK with $ DEBUG_BINARIES=true DEBUG_CLASSFILES=true OPTIMIZATION_LEVEL=NONE make ... When I set a breakpoint (and step one level) I see (gdb) bt #0 jni_GetFieldID (env=0x804fd10, clazz=0x173aa0, name=0x1ae519 "fd", sig=0x1ae500 "Ljava/io/FileDescriptor;") at /home/eric/Java/openjdk_/openjdk/hotspot/src/share/vm/prims/jni.cpp:1626 #1 0x00198ee8 in Java_java_io_FileInputStream_initIDs (env=0x804fd10, fdClass=0x173aa0) at ../../../src/share/native/java/io/FileInputStream.c:52 #2 0xb4ff25aa in ?? () #3 0x0804fd10 in ?? () #4 0x00173aa0 in ?? () #5 0x00173a78 in ?? () #6 0x91657a60 in ?? () #7 0x00173aa4 in ?? () #8 0x91658f30 in ?? () #9 0x00000000 in ?? () Why can't I see the code at #2, ..., #9 ? Thanks. Eric J. -- View this message in context: http://www.nabble.com/gdb-java-tp25474813p25474813.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From Xiaobin.Lu at Sun.COM Wed Sep 16 10:52:11 2009 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Wed, 16 Sep 2009 10:52:11 -0700 Subject: gdb java In-Reply-To: <25474813.post@talk.nabble.com> References: <25474813.post@talk.nabble.com> Message-ID: <4AB125CB.9000700@Sun.COM> I am not sure about why #9's address is 0x000000, but most likely #2 - #8 are JIT compiled code. You should be able to find out what method these address points to by specifying -XX:+UnlockDiagnosticVMOptions -XX:+PrintNMethods as part of the flags to run your application. -Xiaobin On 09/16/09 08:27, ericjoh wrote: > Hi, > > I build the JDK with > $ DEBUG_BINARIES=true DEBUG_CLASSFILES=true OPTIMIZATION_LEVEL=NONE make ... > > When I set a breakpoint (and step one level) I see > > (gdb) bt > #0 jni_GetFieldID (env=0x804fd10, clazz=0x173aa0, name=0x1ae519 "fd", > sig=0x1ae500 "Ljava/io/FileDescriptor;") > at > /home/eric/Java/openjdk_/openjdk/hotspot/src/share/vm/prims/jni.cpp:1626 > #1 0x00198ee8 in Java_java_io_FileInputStream_initIDs (env=0x804fd10, > fdClass=0x173aa0) at > ../../../src/share/native/java/io/FileInputStream.c:52 > #2 0xb4ff25aa in ?? () > #3 0x0804fd10 in ?? () > #4 0x00173aa0 in ?? () > #5 0x00173a78 in ?? () > #6 0x91657a60 in ?? () > #7 0x00173aa4 in ?? () > #8 0x91658f30 in ?? () > #9 0x00000000 in ?? () > > Why can't I see the code at #2, ..., #9 ? > > Thanks. > > Eric J. > > > > From John.Cuthbertson at Sun.COM Wed Sep 16 17:05:58 2009 From: John.Cuthbertson at Sun.COM (john cuthbertson - Sun Microsystems) Date: Wed, 16 Sep 2009 17:05:58 -0700 Subject: gdb java In-Reply-To: <4AB125CB.9000700@Sun.COM> References: <25474813.post@talk.nabble.com> <4AB125CB.9000700@Sun.COM> Message-ID: <4AB17D66.7030607@sun.com> Hi Eric, As Xiaobin says frames 2 to 8 are most likely in dynamically generated code. Since you have broken in JNI code for the native method FileInputStream::initIDs frame #2 is likely to be a native call wrapper or the native method entry code in the interpreter. If you look in debug.cpp there are a number of routines that you can use command line calls to call within your gdb session: > p findpc(0xb4ff25aa) which should print a code blob. You can then use the blob routine to determine the type of code blob. If the code blob is an nmethod (the structure used to hold JIT generated code) then you use the printnm routine: > p printnm(0xb4ff25aa) If the specified address is not in a JIT compiled method then this routine just returns quietly with no output. The zero PC at frame 9 tells me that for some reason gdb was unable to successfully unwind from frame 8. - John Cuthbertson On 09/16/09 10:52, Xiaobin Lu wrote: > I am not sure about why #9's address is 0x000000, but most likely #2 - > #8 are JIT compiled code. You should be able to find out what method > these address points to by specifying -XX:+UnlockDiagnosticVMOptions > -XX:+PrintNMethods as part of the flags to run your application. > > -Xiaobin > > On 09/16/09 08:27, ericjoh wrote: >> Hi, >> >> I build the JDK with >> $ DEBUG_BINARIES=true DEBUG_CLASSFILES=true OPTIMIZATION_LEVEL=NONE >> make ... >> >> When I set a breakpoint (and step one level) I see >> >> (gdb) bt >> #0 jni_GetFieldID (env=0x804fd10, clazz=0x173aa0, name=0x1ae519 >> "fd", sig=0x1ae500 "Ljava/io/FileDescriptor;") >> at >> /home/eric/Java/openjdk_/openjdk/hotspot/src/share/vm/prims/jni.cpp:1626 >> #1 0x00198ee8 in Java_java_io_FileInputStream_initIDs >> (env=0x804fd10, fdClass=0x173aa0) at >> ../../../src/share/native/java/io/FileInputStream.c:52 >> #2 0xb4ff25aa in ?? () >> #3 0x0804fd10 in ?? () >> #4 0x00173aa0 in ?? () >> #5 0x00173a78 in ?? () >> #6 0x91657a60 in ?? () >> #7 0x00173aa4 in ?? () >> #8 0x91658f30 in ?? () >> #9 0x00000000 in ?? () >> >> Why can't I see the code at #2, ..., #9 ? >> >> Thanks. >> >> Eric J. >> >> >> >> > From john.coomes at sun.com Thu Sep 17 20:36:14 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 18 Sep 2009 03:36:14 +0000 Subject: hg: jdk7/hotspot: 3 new changesets Message-ID: <20090918033614.D66D9123D8@hg.openjdk.java.net> Changeset: 4079d923a501 Author: peterz Date: 2009-08-31 14:10 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/4079d923a501 6844267: Nimbus generator depends on JIBX Summary: Nimbus generator now uses JAXB instead of JIBX Reviewed-by: jasper ! README-builds.html Changeset: 0d7e03b426df Author: yan Date: 2009-09-09 00:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/0d7e03b426df Merge Changeset: 4c4fe09fb670 Author: xdono Date: 2009-09-17 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/4c4fe09fb670 Added tag jdk7-b72 for changeset 0d7e03b426df ! .hgtags From john.coomes at sun.com Thu Sep 17 20:36:41 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 18 Sep 2009 03:36:41 +0000 Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b72 for changeset c793a3120926 Message-ID: <20090918033642.E110F123DD@hg.openjdk.java.net> Changeset: 12991b453239 Author: xdono Date: 2009-09-17 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/12991b453239 Added tag jdk7-b72 for changeset c793a3120926 ! .hgtags From john.coomes at sun.com Thu Sep 17 20:39:12 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 18 Sep 2009 03:39:12 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b72 for changeset 37c805b6156f Message-ID: <20090918033915.06B07123E2@hg.openjdk.java.net> Changeset: 93dfa6e0fe76 Author: xdono Date: 2009-09-17 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/93dfa6e0fe76 Added tag jdk7-b72 for changeset 37c805b6156f ! .hgtags From john.coomes at sun.com Thu Sep 17 20:39:43 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 18 Sep 2009 03:39:43 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b72 for changeset 4c990aa99bc0 Message-ID: <20090918033946.5FB1D123E7@hg.openjdk.java.net> Changeset: d79f0d601c2b Author: xdono Date: 2009-09-17 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/d79f0d601c2b Added tag jdk7-b72 for changeset 4c990aa99bc0 ! .hgtags From john.coomes at sun.com Thu Sep 17 20:41:19 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 18 Sep 2009 03:41:19 +0000 Subject: hg: jdk7/hotspot/jdk: 52 new changesets Message-ID: <20090918035236.9C41A123EC@hg.openjdk.java.net> Changeset: b115cf946852 Author: sherman Date: 2009-08-25 15:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b115cf946852 4963968: zlib should be upgraded to current version of zlib Summary: upgrade zlib to the latest ver 1.2.3 Reviewed-by: martin, alanb, ksrini ! make/com/sun/java/pack/Makefile ! make/common/Defs.gmk ! make/java/jli/Makefile ! make/java/zip/FILES_c.gmk ! make/java/zip/Makefile ! make/java/zip/reorder-i586 ! make/java/zip/reorder-sparc ! make/java/zip/reorder-sparcv9 ! make/sun/splashscreen/FILES_c.gmk ! make/sun/splashscreen/Makefile - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h + src/share/native/java/util/zip/zlib-1.2.3/ChangeLog + src/share/native/java/util/zip/zlib-1.2.3/README + src/share/native/java/util/zip/zlib-1.2.3/compress.c + src/share/native/java/util/zip/zlib-1.2.3/crc32.h + src/share/native/java/util/zip/zlib-1.2.3/deflate.c + src/share/native/java/util/zip/zlib-1.2.3/deflate.h + src/share/native/java/util/zip/zlib-1.2.3/gzio.c + src/share/native/java/util/zip/zlib-1.2.3/infback.c + src/share/native/java/util/zip/zlib-1.2.3/inffast.c + src/share/native/java/util/zip/zlib-1.2.3/inffast.h + src/share/native/java/util/zip/zlib-1.2.3/inffixed.h + src/share/native/java/util/zip/zlib-1.2.3/inflate.c + src/share/native/java/util/zip/zlib-1.2.3/inflate.h + src/share/native/java/util/zip/zlib-1.2.3/inftrees.c + src/share/native/java/util/zip/zlib-1.2.3/inftrees.h + src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java + src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff + src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff + src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff + src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff + src/share/native/java/util/zip/zlib-1.2.3/trees.c + src/share/native/java/util/zip/zlib-1.2.3/trees.h + src/share/native/java/util/zip/zlib-1.2.3/uncompr.c + src/share/native/java/util/zip/zlib-1.2.3/zadler32.c + src/share/native/java/util/zip/zlib-1.2.3/zconf.h + src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c + src/share/native/java/util/zip/zlib-1.2.3/zlib.h + src/share/native/java/util/zip/zlib-1.2.3/zutil.c + src/share/native/java/util/zip/zlib-1.2.3/zutil.h Changeset: 196c7bb551e7 Author: darcy Date: 2009-08-25 18:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/196c7bb551e7 6875861: javadoc build warning on java.util.Properites from unconventional @see ordering Reviewed-by: martin ! src/share/classes/java/util/Properties.java Changeset: 2607e571a6d5 Author: weijun Date: 2009-08-26 12:17 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2607e571a6d5 6868864: Kerberos tests fail under windows/cygwin Reviewed-by: wetmore ! test/sun/security/krb5/auto/basic.sh Changeset: 69396f593772 Author: dl Date: 2009-08-25 19:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/69396f593772 6871697: LinkedBlockingQueue Iterator/remove/poll race Summary: More checks for node.next == node Reviewed-by: martin, dholmes, chegar ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java Changeset: aeaf7b138d90 Author: dl Date: 2009-08-25 19:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/aeaf7b138d90 6868712: Improve concurrent queue tests Summary: Fix all known flaky tests, plus minor maintenance Reviewed-by: martin, chegar ! test/java/util/Collection/BiggernYours.java ! test/java/util/Collection/IteratorAtEnd.java ! test/java/util/Collection/MOAT.java ! test/java/util/Collections/RacingCollections.java ! test/java/util/PriorityQueue/RemoveContains.java ! test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/Interrupt.java + test/java/util/concurrent/BlockingQueue/LastElement.java ! test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/OfferDrainToLoops.java ! test/java/util/concurrent/BlockingQueue/PollMemoryLeak.java ! test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java ! test/java/util/concurrent/ConcurrentQueues/ConcurrentQueueLoops.java ! test/java/util/concurrent/ConcurrentQueues/GCRetention.java ! test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java + test/java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java ! test/java/util/concurrent/ConcurrentQueues/RemovePollRace.java - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: 25371bf31658 Author: darcy Date: 2009-08-27 11:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/25371bf31658 6876628: @throw instead of @throws in two ParagraphView classes Reviewed-by: peterz ! src/share/classes/javax/swing/text/ParagraphView.java ! src/share/classes/javax/swing/text/html/ParagraphView.java Changeset: 5342b0cdbf95 Author: xlu Date: 2009-08-27 18:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5342b0cdbf95 6876282: BigDecimal's divide(BigDecimal bd, RoundingFormat r) produces incorrect result Reviewed-by: darcy ! src/share/classes/java/math/BigDecimal.java ! test/java/math/BigDecimal/DivideTests.java Changeset: 4a5f2147f953 Author: darcy Date: 2009-08-28 11:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4a5f2147f953 6877122: Many javadoc warnings from java.awt.Window, other awt classes Reviewed-by: anthony ! src/share/classes/java/awt/Cursor.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/dnd/DragSourceContext.java Changeset: e0f79982edd2 Author: darcy Date: 2009-08-28 14:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e0f79982edd2 6261502: (reflect) Add the functionality to screen out the "inappropriate" modifier bits Reviewed-by: alanb ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Modifier.java Changeset: 225aa5ee10da Author: tbell Date: 2009-08-28 16:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/225aa5ee10da Merge ! src/share/classes/javax/swing/text/ParagraphView.java - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: db5d6b4cbc11 Author: martin Date: 2009-08-31 15:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/db5d6b4cbc11 6860431: Character.isSurrogate(char ch) Summary: Add new method Character.isSurrogate(char ch) Reviewed-by: sherman, darcy, okutsu ! src/share/classes/java/lang/Character.java ! src/share/classes/sun/io/CharToByteDBCS_ASCII.java ! src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java ! src/share/classes/sun/nio/cs/ISO_8859_1.java ! src/share/classes/sun/nio/cs/SingleByte.java ! src/share/classes/sun/nio/cs/SingleByteEncoder.java ! src/share/classes/sun/nio/cs/Surrogate.java ! src/share/classes/sun/nio/cs/US_ASCII.java ! src/share/classes/sun/nio/cs/UTF_32Coder.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/UnicodeDecoder.java ! src/share/classes/sun/nio/cs/UnicodeEncoder.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! src/share/classes/sun/nio/cs/ext/DoubleByteEncoder.java ! src/share/classes/sun/nio/cs/ext/EUC_JP.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java ! src/share/classes/sun/nio/cs/ext/EUC_TW.java ! src/share/classes/sun/nio/cs/ext/GB18030.java ! src/share/classes/sun/nio/cs/ext/ISCII91.java ! src/share/classes/sun/nio/cs/ext/ISO2022.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP.java ! src/share/classes/sun/nio/cs/ext/SimpleEUCEncoder.java Changeset: ed0863629d28 Author: tbell Date: 2009-09-03 18:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ed0863629d28 Merge - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: ee5300e1835a Author: weijun Date: 2009-09-04 14:58 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ee5300e1835a 6876328: different names for the same digest algorithms breaks jarsigner Reviewed-by: mullan ! src/share/classes/sun/security/tools/JarSigner.java + test/sun/security/tools/jarsigner/nameclash.sh Changeset: 98ad1322051e Author: weijun Date: 2009-09-04 14:59 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/98ad1322051e 6871847: AlgorithmId.get("SHA256withECDSA") not available Reviewed-by: vinnie ! src/share/classes/sun/security/x509/AlgorithmId.java + test/sun/security/x509/AlgorithmId/SHA256withECDSA.java Changeset: c34f92a47245 Author: darcy Date: 2009-09-04 13:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c34f92a47245 6873951: test/java/lang/reflect/Generics/Probe.java fails. Reviewed-by: alanb ! test/java/lang/reflect/Generics/Probe.java Changeset: 704296144175 Author: martin Date: 2009-09-04 13:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/704296144175 6879368: Remove stray quote in Character javadoc Summary: Remove stray quote in Character.valueOf javadoc, using Ulf's \u005CuXXXX technique Reviewed-by: darcy ! src/share/classes/java/lang/Character.java Changeset: 658a4255c797 Author: tbell Date: 2009-09-04 17:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/658a4255c797 Merge Changeset: 3f87b755b1c8 Author: alanb Date: 2009-09-04 18:15 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3f87b755b1c8 6873621: (file) FileStore.supportsFileAttributeView(Class type) returns wrong result Reviewed-by: andrew ! src/share/sample/nio/file/Xdd.java ! src/solaris/classes/sun/nio/fs/LinuxFileStore.java ! src/solaris/classes/sun/nio/fs/SolarisFileStore.java ! src/solaris/classes/sun/nio/fs/UnixFileStore.java ! src/windows/classes/sun/nio/fs/WindowsFileStore.java ! test/java/nio/file/FileStore/Basic.java Changeset: 05ea733a7ae2 Author: alanb Date: 2009-09-04 18:17 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/05ea733a7ae2 6868627: (spec) Files.walkFileTree doesn't make it clear that uncaught errors and exceptions are propagated Reviewed-by: sherman ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/SimpleFileVisitor.java Changeset: 87a2ef2439bc Author: alanb Date: 2009-09-04 22:22 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/87a2ef2439bc 6432567: PIT : com/sun/jdi/BadHandshakeTest.java fails due to java.net.ConnectException Reviewed-by: tbell, ohair, dcubed, andrew ! src/share/transport/socket/socketTransport.c ! test/com/sun/jdi/BadHandshakeTest.java Changeset: 7afdf9d0bc2c Author: alanb Date: 2009-09-05 15:57 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7afdf9d0bc2c Merge Changeset: abb69e8b1774 Author: tbell Date: 2009-09-06 23:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/abb69e8b1774 Merge Changeset: 559fb14d0ae9 Author: anthony Date: 2009-08-27 16:42 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/559fb14d0ae9 6780496: Javaw process taking up 80-90 percent of CPU time! Summary: The transparency effects get enabled on showing, and disabled on hiding a window Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h Changeset: 7599cca4fe5e Author: dcherepanov Date: 2009-08-27 17:04 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7599cca4fe5e 6852051: Getting Null Pointer Exception when displaying message for TrayIcon on Opensolaris Reviewed-by: anthony ! src/share/classes/java/awt/Component.java Changeset: 911a82b4901f Author: dcherepanov Date: 2009-08-27 17:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/911a82b4901f 6854898: Frame is located at the negative coordinates instead of origin for Solaris 10 CDE Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XErrorHandler.java ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: d5ac8fb96d13 Author: anthony Date: 2009-08-28 19:34 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d5ac8fb96d13 6689468: test/closed/java/awt/Component/VisibleHwInLwContTest/VisibleHwInLwContTest.html fails Summary: The addNotify() checks whether the component is actually hidden, and hides the peer appropriately if needed Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Component.java Changeset: d755ace580b2 Author: yan Date: 2009-09-04 14:50 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d755ace580b2 6871299: Shift+Tab no longer generates a KEY_TYPED event; used to with JRE 1.5 Summary: Add XK_ISO_Left_Tab -> VK_TAB rule Reviewed-by: dcherepanov ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h Changeset: 5a584fbcc712 Author: yan Date: 2009-09-09 00:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5a584fbcc712 Merge Changeset: a48c15bcf64f Author: rupashka Date: 2009-08-14 13:18 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a48c15bcf64f 6824600: OOM occurs when setLookAndFeel() is executed in Windows L&F(XP style) Reviewed-by: alexp ! src/share/classes/com/sun/java/swing/plaf/windows/DesktopProperty.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalFontDesktopProperty.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java + test/com/sun/java/swing/plaf/windows/Test6824600.java Changeset: fa334ff12794 Author: alexp Date: 2009-08-19 17:24 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fa334ff12794 6872492: JLayer sources contain wrong header Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/plaf/LayerUI.java Changeset: 3e36c9abb569 Author: yan Date: 2009-08-20 23:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3e36c9abb569 Merge - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java Changeset: e8d93257cf7e Author: rupashka Date: 2009-08-21 16:59 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e8d93257cf7e 6579827: vista : JSlider on JColorchooser is not properly render or can't be seen completely. Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java + test/javax/swing/JSlider/6579827/bug6579827.java Changeset: d07bd8fa89e4 Author: rupashka Date: 2009-08-24 18:21 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d07bd8fa89e4 6849266: closed/javax/swing/JFileChooser/6484091/bug6484091.java fails on solaris 10 sparc Reviewed-by: peterz + test/javax/swing/JFileChooser/6484091/bug6484091.java Changeset: 799439873bf9 Author: alexp Date: 2009-08-24 19:22 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/799439873bf9 6824395: Several Swing core components prevent using them in wrapper classes Reviewed-by: peterz ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/JList.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/plaf/LayerUI.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/JLayer/6824395/bug6824395.java ! test/javax/swing/JLayer/SerializationTest/SerializationTest.java Changeset: 4914723317b9 Author: peytoia Date: 2009-08-31 12:55 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4914723317b9 6851214: (tz) New Jordan rule creates a failure for SimpleTimeZone parsing post tzdata2009h Reviewed-by: okutsu ! src/share/classes/java/util/SimpleTimeZone.java + test/java/util/TimeZone/ListTimeZones.java Changeset: 7aa6cb832991 Author: peytoia Date: 2009-08-31 14:50 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7aa6cb832991 6872467: (tz) Support tzdata2009l Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/etcetera ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/factory ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/pacificnew ! make/sun/javazic/tzdata/solar87 ! make/sun/javazic/tzdata/solar88 ! make/sun/javazic/tzdata/solar89 ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/systemv ! make/sun/javazic/tzdata/zone.tab Changeset: 92b6482e7719 Author: peytoia Date: 2009-08-31 14:53 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/92b6482e7719 6456628: (tz) Default timezone is incorrectly set occasionally on Linux Reviewed-by: okutsu ! src/solaris/native/java/util/TimeZone_md.c Changeset: f7d606ca25a9 Author: peterz Date: 2009-08-31 13:46 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f7d606ca25a9 6802944: Nimbus initialization is too slow Reviewed-by: jasper ! make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java ! src/share/classes/javax/swing/plaf/nimbus/Defaults.template ! src/share/classes/javax/swing/plaf/nimbus/DerivedColor.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java Changeset: 7e7153da24ef Author: peterz Date: 2009-08-31 13:56 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7e7153da24ef 6844267: Nimbus generator depends on JIBX Summary: Nimbus generator now uses JAXB instead of JIBX Reviewed-by: jasper ! README ! make/common/Sanity.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/javax/swing/plaf/Makefile - make/javax/swing/plaf/nimbus/Makefile ! make/tools/Makefile + make/tools/generate_nimbus/Makefile + make/tools/src/build/tools/generatenimbus/Generator.java + make/tools/src/build/tools/generatenimbus/ObjectFactory.java + make/tools/src/build/tools/generatenimbus/Paint.java + make/tools/src/build/tools/generatenimbus/PainterGenerator.java + make/tools/src/build/tools/generatenimbus/Shape.java + make/tools/src/build/tools/generatenimbus/SynthModel.java + make/tools/src/build/tools/generatenimbus/UIDefault.java + make/tools/src/build/tools/generatenimbus/UIStyle.java + make/tools/src/build/tools/generatenimbus/Utils.java - make/tools/swing-nimbus/Makefile - make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java Changeset: e7d311b4ae94 Author: alexp Date: 2009-08-31 18:39 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e7d311b4ae94 6872503: JLayer event handling should be rewritten Reviewed-by: art ! src/share/classes/javax/swing/JLayer.java + test/javax/swing/JLayer/6872503/bug6872503.java Changeset: 9d8f551780d5 Author: peytoia Date: 2009-09-01 15:39 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9d8f551780d5 6830423: Unified Ext B character not displayed with Dialog font Reviewed-by: okutsu ! src/windows/classes/sun/awt/windows/fontconfig.properties Changeset: 37c33432e98a Author: peytoia Date: 2009-09-01 15:42 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/37c33432e98a 6838887: (tz) Add UTC and Yerevan to tzmappings Reviewed-by: okutsu ! src/windows/lib/tzmappings Changeset: 5780cff2763c Author: peytoia Date: 2009-09-01 16:15 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5780cff2763c 6856390: RFE : sequence.allfonts.UTF-8.ja for Windows fontconfig.properties Reviewed-by: okutsu ! src/windows/classes/sun/awt/windows/fontconfig.properties Changeset: 4f819e2e0bfc Author: peterz Date: 2009-09-01 15:34 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4f819e2e0bfc 6387579: Usage of package-private class as parameter of a method (javax.swing.tree.DefaultTreeSelectionModel) Reviewed-by: rupashka ! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java Changeset: 935814bd43a6 Author: alexp Date: 2009-09-01 18:51 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/935814bd43a6 6875153: JLayer.isOptimizedDrawingEnabled() throws NPE for null glass pane set Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/plaf/LayerUI.java + test/javax/swing/JLayer/6875153/bug6875153.java Changeset: 281fbd82a971 Author: alexp Date: 2009-09-02 17:47 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/281fbd82a971 6797139: JButton title is truncating for some strings irrespective of preferred size. Reviewed-by: peterz ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuItemLayoutHelper.java ! src/share/classes/sun/swing/MenuItemLayoutHelper.java ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/SwingUtilities/6797139/bug6797139.java Changeset: ff468ef27959 Author: gsm Date: 2009-09-07 12:27 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ff468ef27959 6699856: Creating text in a JTextPane using Chinese text causes undesired behavior Reviewed-by: peterz ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JTextPane.java ! src/share/classes/javax/swing/text/JTextComponent.java Changeset: 01c46cb72eb7 Author: rupashka Date: 2009-09-07 15:09 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/01c46cb72eb7 6589634: Unable to view focus on "Up one level", "create new folder" etc. of JFileChooser Dialog Reviewed-by: peterz, loneid ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java Changeset: d73a741a7ea1 Author: malenkov Date: 2009-09-08 14:08 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d73a741a7ea1 6868185: 2 JCK api/java_beans/Introspector/ tests fails starting from jdk7 b66 Reviewed-by: peterz ! src/share/classes/com/sun/beans/finder/BeanInfoFinder.java Changeset: e289c06b6d36 Author: yan Date: 2009-09-09 00:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e289c06b6d36 Merge - make/javax/swing/plaf/nimbus/Makefile - make/tools/swing-nimbus/Makefile - make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java Changeset: 460639b036f3 Author: yan Date: 2009-09-15 23:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/460639b036f3 Merge - make/javax/swing/plaf/nimbus/Makefile - make/tools/swing-nimbus/Makefile - make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java Changeset: f09a2bfba691 Author: xdono Date: 2009-09-17 13:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f09a2bfba691 Added tag jdk7-b72 for changeset 460639b036f3 ! .hgtags From john.coomes at sun.com Thu Sep 17 20:59:20 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 18 Sep 2009 03:59:20 +0000 Subject: hg: jdk7/hotspot/langtools: 23 new changesets Message-ID: <20090918035959.5793E123F1@hg.openjdk.java.net> Changeset: 40aca381dcaf Author: darcy Date: 2009-08-25 16:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/40aca381dcaf 6872011: Update printing processor to support JSR 308 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java Changeset: 25f15fdd168a Author: darcy Date: 2009-08-26 19:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/25f15fdd168a 6548708: Annotation processing should free service loader if there are no processors Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Changeset: 8109aa93b212 Author: mcimadamore Date: 2009-08-27 13:40 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/8109aa93b212 6840638: Project Coin: Improved Type Inference for Generic Instance Creation (aka 'diamond') Summary: diamond operator implementation (simple approach) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/generics/diamond/neg/Neg01.java + test/tools/javac/generics/diamond/neg/Neg01.out + test/tools/javac/generics/diamond/neg/Neg02.java + test/tools/javac/generics/diamond/neg/Neg02.out + test/tools/javac/generics/diamond/neg/Neg03.java + test/tools/javac/generics/diamond/neg/Neg03.out + test/tools/javac/generics/diamond/neg/Neg04.java + test/tools/javac/generics/diamond/neg/Neg04.out + test/tools/javac/generics/diamond/neg/Neg05.java + test/tools/javac/generics/diamond/neg/Neg05.out + test/tools/javac/generics/diamond/pos/Pos01.java + test/tools/javac/generics/diamond/pos/Pos02.java + test/tools/javac/generics/diamond/pos/Pos03.java + test/tools/javac/generics/diamond/pos/Pos04.java Changeset: ed31953ca025 Author: jjg Date: 2009-08-27 11:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/ed31953ca025 6875336: some tests should use /nodynamiccopyright/ Reviewed-by: darcy ! test/tools/javac/6521805/T6521805a.java ! test/tools/javac/6521805/T6521805a_1.out ! test/tools/javac/6521805/T6521805a_2.out ! test/tools/javac/6521805/T6521805d.java ! test/tools/javac/6521805/T6521805d.out ! test/tools/javac/6717241/T6717241a.java ! test/tools/javac/6717241/T6717241a.out ! test/tools/javac/6717241/T6717241b.java ! test/tools/javac/6717241/T6717241b.out ! test/tools/javac/6734819/T6734819c.java ! test/tools/javac/6734819/T6734819c.out ! test/tools/javac/6758789/T6758789a.java ! test/tools/javac/6758789/T6758789a.out ! test/tools/javac/6758789/T6758789b.java ! test/tools/javac/6758789/T6758789b.out ! test/tools/javac/6840059/T6840059.java ! test/tools/javac/6840059/T6840059.out ! test/tools/javac/Diagnostics/6722234/T6722234a.java ! test/tools/javac/Diagnostics/6722234/T6722234a_1.out ! test/tools/javac/Diagnostics/6722234/T6722234a_2.out ! test/tools/javac/Diagnostics/6722234/T6722234b.java ! test/tools/javac/Diagnostics/6722234/T6722234b_1.out ! test/tools/javac/Diagnostics/6722234/T6722234b_2.out ! test/tools/javac/Diagnostics/6722234/T6722234c.java ! test/tools/javac/Diagnostics/6722234/T6722234c.out ! test/tools/javac/Diagnostics/6722234/T6722234d.java ! test/tools/javac/Diagnostics/6722234/T6722234d_1.out ! test/tools/javac/Diagnostics/6722234/T6722234d_2.out ! test/tools/javac/Diagnostics/6799605/T6799605.java ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/Diagnostics/6860795/T6860795.java ! test/tools/javac/Diagnostics/6860795/T6860795.out ! test/tools/javac/Diagnostics/6862608/T6862608a.java ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/Diagnostics/6862608/T6862608b.java ! test/tools/javac/Diagnostics/6862608/T6862608b.out ! test/tools/javac/Diagnostics/6864382/T6864382.java ! test/tools/javac/Diagnostics/6864382/T6864382.out ! test/tools/javac/OverrideChecks/6199153/T6199153.java ! test/tools/javac/OverrideChecks/6199153/T6199153.out ! test/tools/javac/OverrideChecks/6400189/T6400189a.java ! test/tools/javac/OverrideChecks/6400189/T6400189a.out ! test/tools/javac/OverrideChecks/6400189/T6400189b.java ! test/tools/javac/OverrideChecks/6400189/T6400189b.out ! test/tools/javac/cast/6467183/T6467183a.java ! test/tools/javac/cast/6467183/T6467183a.out ! test/tools/javac/cast/6557182/T6557182.java ! test/tools/javac/cast/6557182/T6557182.out ! test/tools/javac/cast/6665356/T6665356.java ! test/tools/javac/cast/6665356/T6665356.out ! test/tools/javac/cast/6795580/T6795580.java ! test/tools/javac/cast/6795580/T6795580.out ! test/tools/javac/generics/5009937/T5009937.java ! test/tools/javac/generics/5009937/T5009937.out ! test/tools/javac/generics/6182950/T6182950a.java ! test/tools/javac/generics/6182950/T6182950a.out ! test/tools/javac/generics/6182950/T6182950b.java ! test/tools/javac/generics/6182950/T6182950b.out ! test/tools/javac/generics/6677785/T6677785.java ! test/tools/javac/generics/6677785/T6677785.out ! test/tools/javac/generics/6711619/T6711619a.java ! test/tools/javac/generics/6711619/T6711619a.out ! test/tools/javac/generics/6711619/T6711619b.java ! test/tools/javac/generics/6711619/T6711619b.out ! test/tools/javac/generics/6723444/T6723444.java ! test/tools/javac/generics/6723444/T6723444.out ! test/tools/javac/generics/inference/6315770/T6315770.java ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6611449/T6611449.java ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/6638712/T6638712a.java ! test/tools/javac/generics/inference/6638712/T6638712a.out ! test/tools/javac/generics/inference/6638712/T6638712b.java ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712c.java ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712d.java ! test/tools/javac/generics/inference/6638712/T6638712d.out ! test/tools/javac/generics/inference/6638712/T6638712e.java ! test/tools/javac/generics/inference/6638712/T6638712e.out ! test/tools/javac/generics/inference/6718364/T6718364.java ! test/tools/javac/generics/inference/6718364/T6718364.out ! test/tools/javac/generics/rare/6665356/T6665356.java ! test/tools/javac/generics/rare/6665356/T6665356.out ! test/tools/javac/generics/typevars/6569404/T6569404b.java ! test/tools/javac/generics/typevars/6569404/T6569404b.out ! test/tools/javac/generics/typevars/6680106/T6680106.java ! test/tools/javac/generics/typevars/6680106/T6680106.out ! test/tools/javac/generics/typevars/6804733/T6804733.java ! test/tools/javac/generics/typevars/6804733/T6804733.out ! test/tools/javac/typeAnnotations/failures/AnnotationVersion.java ! test/tools/javac/typeAnnotations/failures/AnnotationVersion.out ! test/tools/javac/typeAnnotations/failures/IncompleteArray.java ! test/tools/javac/typeAnnotations/failures/IncompleteArray.out ! test/tools/javac/typeAnnotations/failures/IncompleteVararg.java ! test/tools/javac/typeAnnotations/failures/IncompleteVararg.out ! test/tools/javac/typeAnnotations/failures/IndexArray.java ! test/tools/javac/typeAnnotations/failures/IndexArray.out ! test/tools/javac/typeAnnotations/failures/LintCast.java ! test/tools/javac/typeAnnotations/failures/LintCast.out ! test/tools/javac/typeAnnotations/failures/Scopes.java ! test/tools/javac/typeAnnotations/failures/Scopes.out ! test/tools/javac/typeAnnotations/failures/StaticFields.java ! test/tools/javac/typeAnnotations/failures/StaticFields.out ! test/tools/javac/typeAnnotations/failures/StaticMethods.java ! test/tools/javac/typeAnnotations/failures/StaticMethods.out ! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/target/Constructor.java ! test/tools/javac/typeAnnotations/failures/target/Constructor.out ! test/tools/javac/typeAnnotations/failures/target/IncompleteArray.java ! test/tools/javac/typeAnnotations/failures/target/IncompleteArray.out ! test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.java ! test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.out ! test/tools/javac/typeAnnotations/failures/target/NotTypeUse.java ! test/tools/javac/typeAnnotations/failures/target/NotTypeUse.out ! test/tools/javac/typeAnnotations/failures/target/VoidMethod.java ! test/tools/javac/typeAnnotations/failures/target/VoidMethod.out ! test/tools/javac/varargs/6806876/T6806876.java ! test/tools/javac/varargs/6806876/T6806876.out ! test/tools/javac/warnings/6747671/T6747671.java ! test/tools/javac/warnings/6747671/T6747671.out Changeset: 74760fd5197f Author: jjg Date: 2009-08-27 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/74760fd5197f 6843707: bad tests generate files in the test/ directory 6876699: generated files in repository Reviewed-by: darcy - test/tools/javac/meth/InvokeMH_BAD68.java - test/tools/javac/meth/InvokeMH_BAD72.java ! test/tools/javac/meth/MakeNegTests.sh ! test/tools/javac/quid/MakeNegTests.sh - test/tools/javac/quid/QuotedIdent_BAD61.java - test/tools/javac/quid/QuotedIdent_BAD62.java - test/tools/javac/quid/QuotedIdent_BAD63.java Changeset: 2c20f17c429c Author: jjg Date: 2009-08-27 17:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/2c20f17c429c 6876753: javap tests fail on Windows Reviewed-by: darcy ! test/tools/javap/T4975569.java ! test/tools/javap/T6729471.java ! test/tools/javap/pathsep.sh ! test/tools/javap/stackmap/T6271292.sh Changeset: f29068bfeaed Author: jjg Date: 2009-08-27 17:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/f29068bfeaed 6876755: apt tests fail on Windows Reviewed-by: darcy ! test/tools/apt/Basics/apt.sh ! test/tools/apt/Basics/print.sh ! test/tools/apt/Compile/compile.sh Changeset: 477c5bf1149c Author: jjg Date: 2009-08-27 18:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/477c5bf1149c 6876765: javah tests fail on Windows Reviewed-by: darcy ! test/tools/javah/6257087/foo.sh ! test/tools/javah/ConstMacroTest.sh ! test/tools/javah/MissingParamClassTest.sh ! test/tools/javah/ReadOldClass.sh Changeset: 0ba956343648 Author: jjg Date: 2009-08-28 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/0ba956343648 6876782: two javadoc tests fail on Windows Reviewed-by: darcy ! test/com/sun/javadoc/lib/JavadocTester.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java Changeset: f0c9fc46990b Author: jjg Date: 2009-08-28 14:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/f0c9fc46990b 6877188: some javac shell tests do not work on Windows Reviewed-by: darcy ! test/tools/javac/4846262/Test.sh ! test/tools/javac/6302184/T6302184.sh ! test/tools/javac/ClassPathTest/ClassPathTest.sh ! test/tools/javac/ExtDirs/ExtDirs.sh ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh ! test/tools/javac/javazip/Test.sh ! test/tools/javac/newlines/Newlines.sh ! test/tools/javac/unicode/SupplementaryJavaID6.sh Changeset: ce5be4c09f2a Author: tbell Date: 2009-08-28 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/ce5be4c09f2a Merge - test/tools/javac/meth/InvokeMH_BAD68.java - test/tools/javac/meth/InvokeMH_BAD72.java - test/tools/javac/quid/QuotedIdent_BAD61.java - test/tools/javac/quid/QuotedIdent_BAD62.java - test/tools/javac/quid/QuotedIdent_BAD63.java Changeset: d5e76d422509 Author: jjg Date: 2009-08-31 12:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d5e76d422509 6877229: more javac tests fail on Windows Reviewed-by: darcy ! test/tools/javac/6589361/T6589361.java ! test/tools/javac/MissingInclude.sh ! test/tools/javac/T5090006/compiler.sh ! test/tools/javac/api/6440333/T6440333.java ! test/tools/javac/api/Sibling.java ! test/tools/javac/code/ArrayClone.java ! test/tools/javac/constDebug/ConstDebug.sh ! test/tools/javac/fatalErrors/NoJavaLang.sh ! test/tools/javac/innerClassFile/Driver.sh ! test/tools/javac/quid/QuotedIdent.java ! test/tools/javac/quid/QuotedIdent2.java ! test/tools/javac/stackmap/T4955930.sh Changeset: 4fa458c945ac Author: jjg Date: 2009-08-31 17:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4fa458c945ac 6877744: delete extraneous file Reviewed-by: darcy - test/tools/javac/innerClassFile/Driver.java Changeset: 45301370bc5a Author: jjg Date: 2009-08-31 18:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/45301370bc5a 6877751: test/tools/javac/6627362/T6627362.java fails Reviewed-by: darcy ! test/tools/javac/6627362/T6627362.java Changeset: 5a72ba18c471 Author: jjg Date: 2009-08-31 19:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/5a72ba18c471 6877759: test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java leaves open file Reviewed-by: darcy ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java Changeset: dda7e13f09fb Author: mcimadamore Date: 2009-09-01 14:53 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/dda7e13f09fb 6650759: Inference of formal type parameter (unused in formal parameters) is not performed Summary: propagate inference constraints from 15.12.2.7 to 15.12.2.8 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! test/tools/javac/generics/inference/6302954/T6476073.java ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712e.out + test/tools/javac/generics/inference/6650759/T6650759a.java + test/tools/javac/generics/inference/6650759/T6650759b.java + test/tools/javac/generics/inference/6650759/T6650759c.java + test/tools/javac/generics/inference/6650759/T6650759d.java + test/tools/javac/generics/inference/6650759/T6650759e.java + test/tools/javac/generics/inference/6650759/T6650759f.java + test/tools/javac/generics/inference/6650759/T6650759g.java + test/tools/javac/generics/inference/6650759/T6650759h.java + test/tools/javac/generics/inference/6650759/T6650759i.java + test/tools/javac/generics/inference/6650759/T6650759j.java + test/tools/javac/generics/inference/6650759/T6650759k.java + test/tools/javac/generics/inference/6650759/T6650759l.java + test/tools/javac/generics/inference/6650759/T6650759m.java + test/tools/javac/generics/inference/6650759/T6650759m.out Changeset: 40a1327a5283 Author: jjg Date: 2009-09-01 11:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/40a1327a5283 6877763: update langtools/test/Makefile for JPRT Reviewed-by: ohair ! test/Makefile Changeset: 8d999cb7ec09 Author: jjg Date: 2009-09-02 10:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/8d999cb7ec09 6874249: Check has duplicate local variable and field for "source" Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Check.java Changeset: 90c28923e449 Author: tbell Date: 2009-09-03 18:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/90c28923e449 Merge - test/tools/javac/innerClassFile/Driver.java - test/tools/javac/meth/InvokeMH_BAD68.java - test/tools/javac/meth/InvokeMH_BAD72.java - test/tools/javac/quid/QuotedIdent_BAD61.java - test/tools/javac/quid/QuotedIdent_BAD62.java - test/tools/javac/quid/QuotedIdent_BAD63.java Changeset: 35e29f51a7c3 Author: jjg Date: 2009-09-08 11:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/35e29f51a7c3 6419701: DefaultFileManager clean up: URI.create 6483788: DefaultFileManager.ZipFileObject.toUri() fails to escape space characters 6501502: JSR 199: FileObject.toUri should return file:///c:/ or file:/c:/ not file://c:/ 6877206: JavaFileObject.toUri returns bogus URI (win) 6877223: tests @ignored because of issues with File.toURI on Windows Reviewed-by: mcimadamore, alanb ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! test/tools/javac/Diagnostics/6769027/tester.properties ! test/tools/javac/api/6440333/T6440333.java ! test/tools/javac/api/Sibling.java + test/tools/javac/api/T6483788.java + test/tools/javac/api/T6501502.java + test/tools/javac/api/T6877206.java Changeset: dd98acd9f717 Author: jjg Date: 2009-09-08 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/dd98acd9f717 6879346: files have Windows newlines Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! test/com/sun/javadoc/testCRLineSeparator/TestCRLineSeparator.java ! test/com/sun/javadoc/testCRLineSeparator/pkg/MyClass.java ! test/com/sun/javadoc/testHref/package-list ! test/com/sun/javadoc/testLinkOption/testNewLineInLink/package.html ! test/com/sun/javadoc/testNoPackagesFile/TestNoPackagesFile.java ! test/com/sun/javadoc/testOverridenMethods/TestMultiInheritence.java ! test/com/sun/javadoc/testRelativeLinks/pkg/package.html ! test/com/sun/javadoc/testTaglets/TestTaglets.java ! test/com/sun/javadoc/testWarnings/pkg/package.html ! test/tools/javah/SubClassConsts.win Changeset: 261c54b2312e Author: jjg Date: 2009-09-08 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/261c54b2312e 6879371: javap does not close internal default file manager Reviewed-by: darcy ! src/share/classes/com/sun/tools/javap/JavapTask.java + test/tools/javap/T6879371.java Changeset: bfad32768345 Author: xdono Date: 2009-09-17 13:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/bfad32768345 Added tag jdk7-b72 for changeset 261c54b2312e ! .hgtags From gbenson at redhat.com Fri Sep 18 03:25:37 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 18 Sep 2009 11:25:37 +0100 Subject: Review request: Zero assembler port of HotSpot In-Reply-To: References: <20090817143251.GB3394@redhat.com> Message-ID: <20090918102537.GA3339@redhat.com> Hi Tom, I've been working on a new webrev for Zero. I'm mostly there, but I'd like to check on a couple of points you originally raised. Tom Rodriguez wrote: > I guess I would expect the build directories to look like > linux_i486_zero instead of linux_zero_core which is what I > think you'd currently get. Fixing this is tricky. There is no variable for this directory, it's always referenced as $(OSNAME)_$(BUILDARCH)_whatever, and in addition to specifiying the build directory, BUILDARCH is used in conditionals in various makefiles to add extra compiler flags, etc. If I set BUILDARCH to "i486", for example, then I get a load of extra stuff that isn't wanted. Removing the CORE_BUILD stuff has changed the build directory to linux_zero_zero (which will be linux_zero_shark when Shark is enabled). Is this acceptable? > Shouldn't is_deoptimizer_frame be is_deoptimized_frame? HotSpot's deoptimizer walks the stack in two places, both of which are a C++ function called from the compiled code, so the stack looks like this: (top) Frame of C++ function Frame of compiled method ... When walking the stack, the C++ functions skip over the first frame to find the frame of the compiled method. Zero and Shark maintain a Java stack that is separate from the ABI stack, so the top frame on the stack will be the frame of the compiled method. To give the C++ code a frame to skip, Shark pushes an empty frame onto the stack. That frame is what I've called a deoptimizer frame. Is that ok? Cheers, Gary -- http://gbenson.net/ From andrey.petrusenko at sun.com Fri Sep 18 08:20:22 2009 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Fri, 18 Sep 2009 15:20:22 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20090918152032.526711247F@hg.openjdk.java.net> Changeset: eb058abd0562 Author: ysr Date: 2009-09-15 16:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/eb058abd0562 6861557: G1: assert(top() == bottom() || zfs == Allocated,"Region must be empty, or ...") Summary: Druing heap shrinking, check for emptiness of a region before modifying its ZF status. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp Changeset: d7c9544cc141 Author: apetrusenko Date: 2009-09-18 06:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d7c9544cc141 Merge From ericjvandervelden at gmail.com Fri Sep 18 12:57:00 2009 From: ericjvandervelden at gmail.com (Eric J. Van der Velden) Date: Fri, 18 Sep 2009 12:57:00 -0700 (PDT) Subject: jdb Message-ID: <25514580.post@talk.nabble.com> Hi, I build the JDK by doing $ make debug_build ALT... Now when I use jdb I cannot step into a method of a system type, for example java.util.HashSet.(). Why not, because java/util/HashSet.java is compiled with -g ? Thanks. -- View this message in context: http://www.nabble.com/jdb-tp25514580p25514580.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From Tim.Bell at Sun.COM Fri Sep 18 13:47:22 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Fri, 18 Sep 2009 13:47:22 -0700 Subject: jdb In-Reply-To: <25514580.post@talk.nabble.com> References: <25514580.post@talk.nabble.com> Message-ID: <4AB3F1DA.6000608@sun.com> Eric J. Van der Velden wrote: > I build the JDK by doing > > $ make debug_build ALT... > > Now when I use jdb I cannot step into a method of a system type, for example > java.util.HashSet.(). By default jdb will not step into (or hit breakpoints) in the core implementation classes because it was felt that programmers would be more interested in their own code. jdb starts with a default exclude pattern of: java.*,javax.*,sun.*,com.sun.*, (When in jdb, type 'help' for information about the exclude command). > Why not, because java/util/HashSet.java is compiled with -g ? If you issue the command 'exclude none' in jdb, you will turn off this behavior. BTW - I agree that this jdb behavior is somewhat user surprising, and there is an existing bug report about it: 4702575 "TTY: Warn user before accepting a breakpoint if class is on exclude list" http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4702575 HTH- Tim From vladimir.kozlov at sun.com Fri Sep 18 14:33:42 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 18 Sep 2009 21:33:42 +0000 Subject: hg: hsx/hsx16/baseline: 6880053: assert(alloc_obj->as_CheckCastPP()->type() != TypeInstPtr::NOTNULL) Message-ID: <20090918213346.E632C12534@hg.openjdk.java.net> Changeset: f324a7d7fd56 Author: kvn Date: 2009-09-18 09:47 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/f324a7d7fd56 6880053: assert(alloc_obj->as_CheckCastPP()->type() != TypeInstPtr::NOTNULL) Summary: Removed second CheckCastPP and instead use MembarCPUOrder. Reviewed-by: never ! src/share/vm/opto/library_call.cpp From karen.kinnear at sun.com Fri Sep 18 15:38:54 2009 From: karen.kinnear at sun.com (karen.kinnear at sun.com) Date: Fri, 18 Sep 2009 22:38:54 +0000 Subject: hg: jdk7/hotspot/hotspot: 15 new changesets Message-ID: <20090918223929.E3C5C125A1@hg.openjdk.java.net> Changeset: aafa4232dfd7 Author: asaha Date: 2009-08-28 08:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/aafa4232dfd7 6821003: Update hotspot windows os_win32 for windows 7 Reviewed-by: xlu ! src/os/windows/vm/os_windows.cpp Changeset: 9601152ccfc1 Author: dcubed Date: 2009-08-28 12:25 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9601152ccfc1 6875393: 2/3 JNI itable index cache is broken Summary: Add missing initialization of cache size. Reviewed-by: tbell ! src/share/vm/oops/instanceKlass.cpp Changeset: 75e30968ebe1 Author: dcubed Date: 2009-08-28 12:32 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/75e30968ebe1 Merge ! src/share/vm/oops/instanceKlass.cpp Changeset: df97b1cf46d8 Author: dcubed Date: 2009-08-28 15:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/df97b1cf46d8 Merge Changeset: bb287c042e99 Author: apangin Date: 2009-08-30 15:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bb287c042e99 Merge Changeset: 6918603297f7 Author: poonam Date: 2009-09-01 23:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6918603297f7 6858208: jvm crash when specifying TypeProfileWidth=0 on jdk 6.0 Summary: Add an explicit check for TypeProfileWidth == 0 in record_klass_in_profile_helper() functions. Reviewed-by: never, coleenp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp Changeset: 5fdbe2cdf565 Author: andrew Date: 2009-09-08 09:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5fdbe2cdf565 6879689: Fix warning about ignored return value when compiling with -O2 Summary: Store the return value of fwrite and check it matches the size of the array. Reviewed-by: twisti, dholmes ! src/share/vm/adlc/archDesc.cpp Changeset: 0804a88ed4f5 Author: andrew Date: 2009-09-08 09:02 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0804a88ed4f5 Merge Changeset: 682194ca1d8d Author: acorn Date: 2009-09-10 09:04 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/682194ca1d8d Merge - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp ! src/share/vm/oops/instanceKlass.cpp Changeset: 0fc81f0a8ca8 Author: andrew Date: 2009-09-12 12:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0fc81f0a8ca8 6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk Summary: The build fails if the bootstrap JDK defaults to <1.5 Reviewed-by: jcoomes ! make/linux/makefiles/jvmti.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/jvmti.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/sa.make ! make/solaris/makefiles/top.make ! make/windows/makefiles/generated.make ! make/windows/makefiles/jvmti.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sa.make ! make/windows/projectfiles/common/Makefile Changeset: e5b31fd85b72 Author: acorn Date: 2009-09-15 16:28 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e5b31fd85b72 Merge Changeset: ad6585fd4087 Author: acorn Date: 2009-09-04 12:53 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ad6585fd4087 6830542: Performance: JVM_DefineClass already verified. Reviewed-by: kamg, phh ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 26b774d693aa Author: acorn Date: 2009-09-16 09:10 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/26b774d693aa Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp Changeset: 83c29a26f67c Author: acorn Date: 2009-09-16 15:42 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/83c29a26f67c 6879572: SA fails _is_marked_dependent not found Reviewed-by: kamg, dcubed ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 723131383de6 Author: acorn Date: 2009-09-18 15:14 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/723131383de6 Merge From ericjvandervelden at gmail.com Sat Sep 19 00:29:44 2009 From: ericjvandervelden at gmail.com (Eric J. Van der Velden) Date: Sat, 19 Sep 2009 00:29:44 -0700 (PDT) Subject: jdb In-Reply-To: <4AB3F1DA.6000608@sun.com> References: <25514580.post@talk.nabble.com> <4AB3F1DA.6000608@sun.com> Message-ID: <25519331.post@talk.nabble.com> Hello Tim, Great, thank you very much. Eric J. tim.bell wrote: > > Eric J. Van der Velden wrote: > >> I build the JDK by doing >> >> $ make debug_build ALT... >> >> Now when I use jdb I cannot step into a method of a system type, for >> example >> java.util.HashSet.(). > > By default jdb will not step into (or hit breakpoints) in the core > implementation classes because it was felt that programmers would be > more interested in their own code. > > jdb starts with a default exclude pattern of: > java.*,javax.*,sun.*,com.sun.*, > > > (When in jdb, type 'help' for information about the exclude command). > >> Why not, because java/util/HashSet.java is compiled with -g ? > > If you issue the command 'exclude none' in jdb, you will turn off > this behavior. > > BTW - I agree that this jdb behavior is somewhat user surprising, > and there is an existing bug report about it: > > 4702575 "TTY: Warn user before accepting a breakpoint if class is on > exclude list" > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4702575 > > > HTH- > > Tim > > -- View this message in context: http://www.nabble.com/jdb-tp25514580p25519331.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From Thomas.Rodriguez at Sun.COM Mon Sep 21 10:48:07 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 21 Sep 2009 10:48:07 -0700 Subject: Review request: Zero assembler port of HotSpot In-Reply-To: <20090918102537.GA3339@redhat.com> References: <20090817143251.GB3394@redhat.com> <20090918102537.GA3339@redhat.com> Message-ID: On Sep 18, 2009, at 3:25 AM, Gary Benson wrote: > Hi Tom, > > I've been working on a new webrev for Zero. I'm mostly there, > but I'd like to check on a couple of points you originally raised. > > Tom Rodriguez wrote: >> I guess I would expect the build directories to look like >> linux_i486_zero instead of linux_zero_core which is what I >> think you'd currently get. > > Fixing this is tricky. There is no variable for this directory, > it's always referenced as $(OSNAME)_$(BUILDARCH)_whatever, and > in addition to specifiying the build directory, BUILDARCH is > used in conditionals in various makefiles to add extra compiler > flags, etc. If I set BUILDARCH to "i486", for example, then I > get a load of extra stuff that isn't wanted. > > Removing the CORE_BUILD stuff has changed the build directory > to linux_zero_zero (which will be linux_zero_shark when Shark > is enabled). Is this acceptable? I'm going to look into making it work the way I want. The logic is mainly driven through buildtree.make and I recently was experimenting with driving that differently so I think I can see how to do it. I'll take a stab and get back to you. If I can't then linux_zero_zero will have to do. > >> Shouldn't is_deoptimizer_frame be is_deoptimized_frame? > > HotSpot's deoptimizer walks the stack in two places, both of > which are a C++ function called from the compiled code, so the > stack looks like this: > > (top) Frame of C++ function > Frame of compiled method > ... If I understand you correctly, it's really this case: c++ (fetch_unroll_info) deopt blob compiled frame > When walking the stack, the C++ functions skip over the first > frame to find the frame of the compiled method. Zero and Shark > maintain a Java stack that is separate from the ABI stack, so > the top frame on the stack will be the frame of the compiled > method. To give the C++ code a frame to skip, Shark pushes an > empty frame onto the stack. That frame is what I've called a > deoptimizer frame. Is that ok? So it's just a dummy frame to make the idiom below work? frame stub_frame = thread->last_frame(); frame caller_frame = stub_frame.sender(®_map); Do you insert dummy stub frames to deal with other places that use that idiom or are you not using entry points that have that pattern? tom > > Cheers, > Gary > > -- > http://gbenson.net/ From gnu_andrew at member.fsf.org Mon Sep 21 15:39:10 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 21 Sep 2009 23:39:10 +0100 Subject: Build failure with new functions introduced in fix for 4957990 Message-ID: <17c6771e0909211539j16d52f08ub9c6f4c4d4bf706d@mail.gmail.com> This changeset: http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/8b46c4d82093 was promoted as part of b72 and fixes http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4957990. It's nice to see a long-running bug being resolved, but unfortunately I've run into an issue with the fix. In markSweep.hpp and psParallelCompact.hpp, two new functions are introduced: + static void follow_mdo_weak_refs(); + static void revisit_mdo(ParCompactionManager* cm, DataLayout* p); However, in markSweep.cpp and psParallelCompact.cpp, these are only implemented conditionally: +#if ( defined(COMPILER1) || defined(COMPILER2) ) +void MarkSweep::revisit_mdo(DataLayout* p) { + _revisit_mdo_stack->push(p); +} + etc... If neither COMPILER1 nor COMPILER2 are defined (as is the case with building Gary Benson's zero port: http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001957.html for example), then the build now fails: Linking launcher... /mnt/builder/icedtea/hotspot/outputdir/linux_zero_core/product/libjvm.so: undefined reference to `PSParallelCompact::revisit_mdo(ParCompactionManager*, DataLayout*)' /mnt/builder/icedtea/hotspot/outputdir/linux_zero_core/product/libjvm.so: undefined reference to `MarkSweep::revisit_mdo(DataLayout*)' /mnt/builder/icedtea/hotspot/outputdir/linux_zero_core/product/libjvm.so: undefined reference to `MarkSweep::follow_mdo_weak_refs()' /mnt/builder/icedtea/hotspot/outputdir/linux_zero_core/product/libjvm.so: undefined reference to `PSParallelCompact::follow_mdo_weak_refs()' collect2: ld returned 1 exit status The obvious fix that springs to mind is to add an #else block that implements these with ShouldNotCallThis() as in this webrev: http://cr.openjdk.java.net/~andrew/hotspot/webrev.01/ but I'm not sure if that's the correct fix. Any ideas? Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Y.S.Ramakrishna at Sun.COM Mon Sep 21 15:53:47 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Mon, 21 Sep 2009 15:53:47 -0700 Subject: Build failure with new functions introduced in fix for 4957990 In-Reply-To: <17c6771e0909211539j16d52f08ub9c6f4c4d4bf706d@mail.gmail.com> References: <17c6771e0909211539j16d52f08ub9c6f4c4d4bf706d@mail.gmail.com> Message-ID: <4AB803FB.5030606@Sun.COM> Hi Andrew -- I _think_ you should be able to just remove the #ifdef's entirely, and it should work. (I don't know what i was trying to achieve w/the #ifdef, but the rationale was probably obsoleted during the long (several years!) gestation period of that changeset before it was, ummm, pushed.) Let me know if there are any issues. -- ramki On 09/21/09 15:39, Andrew John Hughes wrote: > This changeset: > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/8b46c4d82093 > > was promoted as part of b72 and fixes > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4957990. It's nice > to see a long-running bug being resolved, but unfortunately I've run > into an issue with the fix. > > In markSweep.hpp and psParallelCompact.hpp, two new functions are introduced: > > + static void follow_mdo_weak_refs(); > + static void revisit_mdo(ParCompactionManager* cm, DataLayout* p); > > However, in markSweep.cpp and psParallelCompact.cpp, these are only > implemented conditionally: > > +#if ( defined(COMPILER1) || defined(COMPILER2) ) > +void MarkSweep::revisit_mdo(DataLayout* p) { > + _revisit_mdo_stack->push(p); > +} > + > etc... > > If neither COMPILER1 nor COMPILER2 are defined (as is the case with > building Gary Benson's zero port: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001957.html > for example), then the build now fails: > > Linking launcher... > /mnt/builder/icedtea/hotspot/outputdir/linux_zero_core/product/libjvm.so: > undefined reference to > `PSParallelCompact::revisit_mdo(ParCompactionManager*, DataLayout*)' > /mnt/builder/icedtea/hotspot/outputdir/linux_zero_core/product/libjvm.so: > undefined reference to `MarkSweep::revisit_mdo(DataLayout*)' > /mnt/builder/icedtea/hotspot/outputdir/linux_zero_core/product/libjvm.so: > undefined reference to `MarkSweep::follow_mdo_weak_refs()' > /mnt/builder/icedtea/hotspot/outputdir/linux_zero_core/product/libjvm.so: > undefined reference to `PSParallelCompact::follow_mdo_weak_refs()' > collect2: ld returned 1 exit status > > The obvious fix that springs to mind is to add an #else block that > implements these with ShouldNotCallThis() as in this webrev: > > http://cr.openjdk.java.net/~andrew/hotspot/webrev.01/ > > but I'm not sure if that's the correct fix. > > Any ideas? > > Thanks, From gbenson at redhat.com Tue Sep 22 01:38:26 2009 From: gbenson at redhat.com (Gary Benson) Date: Tue, 22 Sep 2009 09:38:26 +0100 Subject: Review request: Zero assembler port of HotSpot In-Reply-To: References: <20090817143251.GB3394@redhat.com> <20090918102537.GA3339@redhat.com> Message-ID: <20090922083825.GA3527@redhat.com> Tom Rodriguez wrote: > On Sep 18, 2009, at 3:25 AM, Gary Benson wrote: > > Tom Rodriguez wrote: > > > I guess I would expect the build directories to look like > > > linux_i486_zero instead of linux_zero_core which is what I > > > think you'd currently get. > > > > Fixing this is tricky. There is no variable for this directory, > > it's always referenced as $(OSNAME)_$(BUILDARCH)_whatever, and > > in addition to specifiying the build directory, BUILDARCH is > > used in conditionals in various makefiles to add extra compiler > > flags, etc. If I set BUILDARCH to "i486", for example, then I > > get a load of extra stuff that isn't wanted. > > > > Removing the CORE_BUILD stuff has changed the build directory > > to linux_zero_zero (which will be linux_zero_shark when Shark > > is enabled). Is this acceptable? > > I'm going to look into making it work the way I want. The logic is > mainly driven through buildtree.make and I recently was experimenting > with driving that differently so I think I can see how to do it. I'll > take a stab and get back to you. If I can't then linux_zero_zero will > have to do. I'll make a new webrev so you can work on the partially right one. > > > Shouldn't is_deoptimizer_frame be is_deoptimized_frame? > > > > HotSpot's deoptimizer walks the stack in two places, both of > > which are a C++ function called from the compiled code, so the > > stack looks like this: > > > > (top) Frame of C++ function > > Frame of compiled method > > ... > > If I understand you correctly, it's really this case: > > c++ (fetch_unroll_info) > deopt blob > compiled frame I was mistaken about it being a C++ frame (it's been a while since I wrote this code). The two places that walk the stack during a deopt (Deoptimization::uncommon_trap_inner and Deoptimization::unpack_frames) both use use JavaThread::last_frame(). The frame it's skipping is the deopt stub's frame. > So it's just a dummy frame to make the idiom below work? > > frame stub_frame = thread->last_frame(); > frame caller_frame = stub_frame.sender(®_map); Yes. Maybe it would be better to rename DEOPTIMIZER_FRAME as something like EMPTY_FRAME or DUMMY_FRAME? > Do you insert dummy stub frames to deal with other places that use > that idiom or are you not using entry points that have that pattern? There's nowhere else in Zero or Shark that creates dummy frames like this. Cheers, Gary -- http://gbenson.net/ From gnu_andrew at member.fsf.org Tue Sep 22 08:17:07 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 22 Sep 2009 16:17:07 +0100 Subject: Build failure with new functions introduced in fix for 4957990 In-Reply-To: <4AB803FB.5030606@Sun.COM> References: <17c6771e0909211539j16d52f08ub9c6f4c4d4bf706d@mail.gmail.com> <4AB803FB.5030606@Sun.COM> Message-ID: <17c6771e0909220817q6443b3f8g789f300b47d57c0f@mail.gmail.com> 2009/9/21 : > Hi Andrew -- > > I _think_ you should be able to just remove the > #ifdef's entirely, and it should work. (I don't know > what i was trying to achieve w/the #ifdef, but the > rationale was probably obsoleted during the long (several years!) > gestation period of that changeset before it was, ummm, > pushed.) > > Let me know if there are any issues. > -- ramki > > On 09/21/09 15:39, Andrew John Hughes wrote: >> >> This changeset: >> >> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/8b46c4d82093 >> >> was promoted as part of b72 and fixes >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4957990. ?It's nice >> to see a long-running bug being resolved, but unfortunately I've run >> into an issue with the fix. >> >> In markSweep.hpp and psParallelCompact.hpp, two new functions are >> introduced: >> >> + static void follow_mdo_weak_refs(); >> + static void revisit_mdo(ParCompactionManager* cm, DataLayout* p); >> >> However, in markSweep.cpp and psParallelCompact.cpp, these are only >> implemented conditionally: >> >> +#if ( defined(COMPILER1) || defined(COMPILER2) ) >> +void MarkSweep::revisit_mdo(DataLayout* p) { >> + _revisit_mdo_stack->push(p); >> +} >> + >> etc... >> >> If neither COMPILER1 nor COMPILER2 are defined (as is the case with >> building Gary Benson's zero port: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001957.html >> for example), then the build now fails: >> >> Linking launcher... >> /mnt/builder/icedtea/hotspot/outputdir/linux_zero_core/product/libjvm.so: >> undefined reference to >> `PSParallelCompact::revisit_mdo(ParCompactionManager*, DataLayout*)' >> /mnt/builder/icedtea/hotspot/outputdir/linux_zero_core/product/libjvm.so: >> undefined reference to `MarkSweep::revisit_mdo(DataLayout*)' >> /mnt/builder/icedtea/hotspot/outputdir/linux_zero_core/product/libjvm.so: >> undefined reference to `MarkSweep::follow_mdo_weak_refs()' >> /mnt/builder/icedtea/hotspot/outputdir/linux_zero_core/product/libjvm.so: >> undefined reference to `PSParallelCompact::follow_mdo_weak_refs()' >> collect2: ld returned 1 exit status >> >> The obvious fix that springs to mind is to add an #else block that >> implements these with ShouldNotCallThis() as in this webrev: >> >> http://cr.openjdk.java.net/~andrew/hotspot/webrev.01/ >> >> but I'm not sure if that's the correct fix. >> >> Any ideas? >> >> Thanks, > > Ah, that's good, I was worried about just having no implementation of part of the GC. With: http://cr.openjdk.java.net/~andrew/hotspot/webrev.02/hotspot.patch and turning off compressed oops, I've been able to build a working Zero-based HotSpot build with b72. Can you assign this a bug ID and put the webrev through jprt to get it applied? Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Y.S.Ramakrishna at Sun.COM Tue Sep 22 10:46:36 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Tue, 22 Sep 2009 10:46:36 -0700 Subject: Build failure with new functions introduced in fix for 4957990 In-Reply-To: <17c6771e0909220817q6443b3f8g789f300b47d57c0f@mail.gmail.com> References: <17c6771e0909211539j16d52f08ub9c6f4c4d4bf706d@mail.gmail.com> <4AB803FB.5030606@Sun.COM> <17c6771e0909220817q6443b3f8g789f300b47d57c0f@mail.gmail.com> Message-ID: <4AB90D7C.2030807@Sun.COM> Will do. Thanks! -- ramki On 09/22/09 08:17, Andrew John Hughes wrote: > 2009/9/21 : >> Hi Andrew -- >> >> I _think_ you should be able to just remove the >> #ifdef's entirely, and it should work. (I don't know >> what i was trying to achieve w/the #ifdef, but the >> rationale was probably obsoleted during the long (several years!) >> gestation period of that changeset before it was, ummm, >> pushed.) >> >> Let me know if there are any issues. >> -- ramki >> >> On 09/21/09 15:39, Andrew John Hughes wrote: >>> This changeset: >>> >>> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/8b46c4d82093 >>> >>> was promoted as part of b72 and fixes >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4957990. It's nice >>> to see a long-running bug being resolved, but unfortunately I've run >>> into an issue with the fix. >>> >>> In markSweep.hpp and psParallelCompact.hpp, two new functions are >>> introduced: >>> >>> + static void follow_mdo_weak_refs(); >>> + static void revisit_mdo(ParCompactionManager* cm, DataLayout* p); >>> >>> However, in markSweep.cpp and psParallelCompact.cpp, these are only >>> implemented conditionally: >>> >>> +#if ( defined(COMPILER1) || defined(COMPILER2) ) >>> +void MarkSweep::revisit_mdo(DataLayout* p) { >>> + _revisit_mdo_stack->push(p); >>> +} >>> + >>> etc... >>> >>> If neither COMPILER1 nor COMPILER2 are defined (as is the case with >>> building Gary Benson's zero port: >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001957.html >>> for example), then the build now fails: >>> >>> Linking launcher... >>> /mnt/builder/icedtea/hotspot/outputdir/linux_zero_core/product/libjvm.so: >>> undefined reference to >>> `PSParallelCompact::revisit_mdo(ParCompactionManager*, DataLayout*)' >>> /mnt/builder/icedtea/hotspot/outputdir/linux_zero_core/product/libjvm.so: >>> undefined reference to `MarkSweep::revisit_mdo(DataLayout*)' >>> /mnt/builder/icedtea/hotspot/outputdir/linux_zero_core/product/libjvm.so: >>> undefined reference to `MarkSweep::follow_mdo_weak_refs()' >>> /mnt/builder/icedtea/hotspot/outputdir/linux_zero_core/product/libjvm.so: >>> undefined reference to `PSParallelCompact::follow_mdo_weak_refs()' >>> collect2: ld returned 1 exit status >>> >>> The obvious fix that springs to mind is to add an #else block that >>> implements these with ShouldNotCallThis() as in this webrev: >>> >>> http://cr.openjdk.java.net/~andrew/hotspot/webrev.01/ >>> >>> but I'm not sure if that's the correct fix. >>> >>> Any ideas? >>> >>> Thanks, >> > > Ah, that's good, I was worried about just having no implementation of > part of the GC. > > With: > > http://cr.openjdk.java.net/~andrew/hotspot/webrev.02/hotspot.patch > > and turning off compressed oops, I've been able to build a working > Zero-based HotSpot build with b72. > > Can you assign this a bug ID and put the webrev through jprt to get it applied? > > Thanks, From Thomas.Rodriguez at Sun.COM Tue Sep 22 22:20:52 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 22 Sep 2009 22:20:52 -0700 Subject: Review request: Zero assembler port of HotSpot In-Reply-To: <20090922083825.GA3527@redhat.com> References: <20090817143251.GB3394@redhat.com> <20090918102537.GA3339@redhat.com> <20090922083825.GA3527@redhat.com> Message-ID: <24172BAD-1F91-4D0F-AF07-B70042A2B0D1@Sun.COM> >> I'm going to look into making it work the way I want. The logic is >> mainly driven through buildtree.make and I recently was experimenting >> with driving that differently so I think I can see how to do it. >> I'll >> take a stab and get back to you. If I can't then linux_zero_zero >> will >> have to do. > > I'll make a new webrev so you can work on the partially right one. OK. > So it's just a dummy frame to make the idiom below work? >> >> frame stub_frame = thread->last_frame(); >> frame caller_frame = stub_frame.sender(®_map); > > Yes. Maybe it would be better to rename DEOPTIMIZER_FRAME as > something like EMPTY_FRAME or DUMMY_FRAME? Yes. Maybe dummy stub frame to be explicit? > >> Do you insert dummy stub frames to deal with other places that use >> that idiom or are you not using entry points that have that pattern? > > There's nowhere else in Zero or Shark that creates dummy frames like > this. So I guess this means you never use any of the other compiled stub entry points. Maybe the deopt entry points could be refactored so shark doesn't need a fake frame. Would that make sense? tom > > Cheers, > Gary > > -- > http://gbenson.net/ From gbenson at redhat.com Wed Sep 23 09:00:10 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 23 Sep 2009 17:00:10 +0100 Subject: Review request: Zero assembler port of HotSpot In-Reply-To: <24172BAD-1F91-4D0F-AF07-B70042A2B0D1@Sun.COM> References: <20090817143251.GB3394@redhat.com> <20090918102537.GA3339@redhat.com> <20090922083825.GA3527@redhat.com> <24172BAD-1F91-4D0F-AF07-B70042A2B0D1@Sun.COM> Message-ID: <20090923160009.GE3271@redhat.com> Tom Rodriguez wrote: > > > I'm going to look into making it work the way I want. The logic > > > is mainly driven through buildtree.make and I recently was > > > experimenting with driving that differently so I think I can see > > > how to do it. I'll take a stab and get back to you. If I can't > > > then linux_zero_zero will have to do. > > > > I'll make a new webrev so you can work on the partially right one. > > OK. http://cr.openjdk.java.net/~gbenson/zero-10/ I'll mail the list tomorrow (it's end of day here) detailing the changes since the last one you reviewed, but you should be able to build it using exactly the same variables. > > > Do you insert dummy stub frames to deal with other places that > > > use that idiom or are you not using entry points that have that > > > pattern? > > > > There's nowhere else in Zero or Shark that creates dummy frames > > like this. > > So I guess this means you never use any of the other compiled stub > entry points. Maybe the deopt entry points could be refactored so > shark doesn't need a fake frame. Would that make sense? It would be possible, though that would require a fair amount of conditionalized code in deoptimization.cpp. Cheers, Gary -- http://gbenson.net/ From gnu_andrew at member.fsf.org Wed Sep 23 09:05:04 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 23 Sep 2009 17:05:04 +0100 Subject: Review request: Zero assembler port of HotSpot In-Reply-To: <20090923160009.GE3271@redhat.com> References: <20090817143251.GB3394@redhat.com> <20090918102537.GA3339@redhat.com> <20090922083825.GA3527@redhat.com> <24172BAD-1F91-4D0F-AF07-B70042A2B0D1@Sun.COM> <20090923160009.GE3271@redhat.com> Message-ID: <17c6771e0909230905x5fcc80a1x1e3a08bac0d582e1@mail.gmail.com> 2009/9/23 Gary Benson : > Tom Rodriguez wrote: >> > > I'm going to look into making it work the way I want. ?The logic >> > > is mainly driven through buildtree.make and I recently was >> > > experimenting with driving that differently so I think I can see >> > > how to do it. ?I'll take a stab and get back to you. ?If I can't >> > > then linux_zero_zero will have to do. >> > >> > I'll make a new webrev so you can work on the partially right one. >> >> OK. > > http://cr.openjdk.java.net/~gbenson/zero-10/ > > I'll mail the list tomorrow (it's end of day here) detailing the > changes since the last one you reviewed, but you should be able to > build it using exactly the same variables. > That worked for me, though I guess CORE_BUILD is now redundant. >> > > Do you insert dummy stub frames to deal with other places that >> > > use that idiom or are you not using entry points that have that >> > > pattern? >> > >> > There's nowhere else in Zero or Shark that creates dummy frames >> > like this. >> >> So I guess this means you never use any of the other compiled stub >> entry points. ?Maybe the deopt entry points could be refactored so >> shark doesn't need a fake frame. ?Would that make sense? > > It would be possible, though that would require a fair amount of > conditionalized code in deoptimization.cpp. > > Cheers, > Gary > > -- > http://gbenson.net/ > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gbenson at redhat.com Wed Sep 23 09:17:51 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 23 Sep 2009 17:17:51 +0100 Subject: Review request: Zero assembler port of HotSpot In-Reply-To: <17c6771e0909230905x5fcc80a1x1e3a08bac0d582e1@mail.gmail.com> References: <20090817143251.GB3394@redhat.com> <20090918102537.GA3339@redhat.com> <20090922083825.GA3527@redhat.com> <24172BAD-1F91-4D0F-AF07-B70042A2B0D1@Sun.COM> <20090923160009.GE3271@redhat.com> <17c6771e0909230905x5fcc80a1x1e3a08bac0d582e1@mail.gmail.com> Message-ID: <20090923161750.GF3271@redhat.com> Andrew John Hughes wrote: > 2009/9/23 Gary Benson : > > Tom Rodriguez wrote: > > > > > I'm going to look into making it work the way I want. ?The > > > > > logic is mainly driven through buildtree.make and I recently > > > > > was experimenting with driving that differently so I think I > > > > > can see how to do it. ?I'll take a stab and get back to > > > > > you. ?If I can't then linux_zero_zero will have to do. > > > > > > > > I'll make a new webrev so you can work on the partially right > > > > one. > > > > > > OK. > > > > http://cr.openjdk.java.net/~gbenson/zero-10/ > > > > I'll mail the list tomorrow (it's end of day here) detailing the > > changes since the last one you reviewed, but you should be able > > to build it using exactly the same variables. > > That worked for me, though I guess CORE_BUILD is now redundant. Yeah, CORE_BUILD isn't used any more. Cheers, Gary -- http://gbenson.net/ From Xiaobin.Lu at Sun.COM Wed Sep 23 16:13:37 2009 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Wed, 23 Sep 2009 16:13:37 -0700 Subject: CR review request for 6880029 Message-ID: <4ABAABA1.50301@Sun.COM> Webrev: http://cr.openjdk.java.net/~xlu/6880029/webrev.00/ Details: When "PrintSafepointStatistics" is set, safepoint statistics will be printed out when any safepoint reached. The current implementation has a race when after "os::make_polling_page_unreacheable" is called, but before "begin_statistics" is getting called. The problem is that the compiler thread might call SafepointSynchronize::handle_polling_page_exception during this time window, and call inc_page_count to increment the page trap count. The page trap count is stored in an array which hasn't been malloc'ed at this point however. A fix is to move the initialization up before we call os::making_polling_page_unreacheable and that is what I am doing in the webrev. One thing to notice is that we have to check both PrintSafepointStatistics and PrintStafepointStatisticsTimeout before deferred_initilize_stat is called since both flag can be specified separately. After the initialization, we can rely solely on PrintSafepointStatistics. Thanks in advance! -Xiaobin From Thomas.Rodriguez at Sun.COM Wed Sep 23 16:21:52 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 23 Sep 2009 16:21:52 -0700 Subject: CR review request for 6880029 In-Reply-To: <4ABAABA1.50301@Sun.COM> References: <4ABAABA1.50301@Sun.COM> Message-ID: <1F91EAAF-5777-4F02-B14C-DA865746AA83@sun.com> That looks much better. Any reason not to put it above the _state = _synchronizing statement? That's really the first point where a thread could begin to see that a safepoint is occurring and it would avoid any later changes to statistics collection running into the same initialization problem. tom On Sep 23, 2009, at 4:13 PM, Xiaobin Lu wrote: > Webrev: http://cr.openjdk.java.net/~xlu/6880029/webrev.00/ > > Details: > > When "PrintSafepointStatistics" is set, safepoint statistics will be > printed out when any safepoint reached. The current implementation > has a race when after "os::make_polling_page_unreacheable" is > called, but before "begin_statistics" is getting called. The problem > is that the compiler thread might call > SafepointSynchronize::handle_polling_page_exception during this time > window, and call inc_page_count to increment the page trap count. > The page trap count is stored in an array which hasn't been > malloc'ed at this point however. > > A fix is to move the initialization up before we call > os::making_polling_page_unreacheable and that is what I am doing in > the webrev. One thing to notice is that we have to check both > PrintSafepointStatistics and PrintStafepointStatisticsTimeout before > deferred_initilize_stat is called since both flag can be specified > separately. After the initialization, we can rely solely on > PrintSafepointStatistics. > > Thanks in advance! > > -Xiaobin > > From Xiaobin.Lu at Sun.COM Wed Sep 23 16:32:03 2009 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Wed, 23 Sep 2009 16:32:03 -0700 Subject: CR review request for 6880029 In-Reply-To: <1F91EAAF-5777-4F02-B14C-DA865746AA83@sun.com> References: <4ABAABA1.50301@Sun.COM> <1F91EAAF-5777-4F02-B14C-DA865746AA83@sun.com> Message-ID: <4ABAAFF3.6040700@Sun.COM> On 09/23/09 16:21, Tom Rodriguez wrote: > That looks much better. Any reason not to put it above the _state = > _synchronizing statement? A nice thought. I put in the current place simply because there is no other code depending on that except for the polling page handling. But I agree with you that moving it above _state=_synchronizing is probably right place to avoid any future trouble.... -Xiaobin From gbenson at redhat.com Thu Sep 24 05:56:31 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 24 Sep 2009 13:56:31 +0100 Subject: Second Zero review request Message-ID: <20090924125631.GD3292@redhat.com> Hi all, Zero is an interpreter-only port of HotSpot that uses no assembler and can trivially be built on any Linux system. The following webrev adds Zero support to OpenJDK: http://cr.openjdk.java.net/~gbenson/zero-10/ Building is largely the same as the previous webrev (zero-07) except for the following changes: - The variable CORE_BUILD is no longer used. - The variable ZERO_BITSPERWORD has been replaced with ARCH_DATA_MODEL Summary of changes ================== - The code has been reformatted to better match HotSpot's coding conventions. Notably, all opening braces have been moved to the end of the previous line, rather than being on their own lines. - The variable CORE_BUILD is no longer required. Setting ZERO_BUILD is all that is required to enable Zero. - The Zero build process no longer hijacks the core rules in the makefiles, but provides its own rules. A consequence of this is that the build directory is now linux_zero_zero rather than linux_zero_core. Another consequence is that Zero now has its own includeDB file, into which all direct #includes have been moved. - The variable ZERO_BITSPERWORD has been replaced with the existing ARCH_DATA_MODEL. - The type definition ZeroEntry::method_entry_t has been renamed. Tom Rodriguez suggested MethodEntryFunc, but Zero now supports OSR, which requires a different calling convention, so there is now ZeroEntry::NormalEntryFunc and ZeroEntry::OSREntryFunc. - Zero no longer hijacks C2_BASE_DIR in hotspot/make/Makefile. ZERO_BASE_DIR is used instead. - A duplicate definition of STATIC_CXX was removed. - Zero's ICache now overrides some AbstractICache methods with empty methods, avoiding conditionals in icache.cpp. Comments in icache_zero.hpp explain this rationale. - JNIHandles::clear is now protected on all platforms, not just Zero. - Code from the ZeroStackPrinter class has been migrated to methods in ZeroFrame and its subclasses. stackPrinter_zero.hpp (previously directly included from vmError.cpp) has been removed, and most of the Zero-specific code in VMError::report has likewise been replaced. There is still a small amount of conditional code in VMError::report, but this could be removed entirely if it is not acceptable (at the expense of losing the super-detailed stack traces that Zero emits, eg http://tinyurl.com/y9rp4r3). - frame::frame uses find_blob_unsafe instead of find_blob. - All stubs contain ShouldNotCallThis() instead of Unimplemented(). Summary of non-changes ====================== - The variable ZERO_ENDIANNESS remains unchanged. I haven't renamed it as ENDIANNESS because it's only used during Zero builds. It's possible that the makefiles could be refactored such that, for example, existing platforms set ENDIANNESS (leaving Zero requiring it to be set externally) but I wasn't sure I should be doing this in this patch. - The build directory is linux_zero_zero (or linux_zero_shark) rather than linux_$(ARCH)_zero. There is no variable defining the name of the build directory as such, it's always referenced as $(OSNAME)_$(BUILDARCH)_whatever, and in addition to specifiying the build directory, BUILDARCH is used in conditionals in various makefiles to add extra compiler flags, etc. If BUILDARCH is set to "i486", for example, then extra compiler flags are added which are unnecessary (and possibly problematic) for Zero. - The variable ZERO_LIBARCH remains. It's used in several different places, and I couldn't figure out a place to put the logic to convert a uname string to the correct ZERO_LIBARCH value where the result would be accessible everywhere it is required. Build Instructions ================== There are a number of environment variables that need setting before running make, but if you are using jdk/make/jdk_generic_profile.sh to set up your environment then you only need to set one, and a build can be as simple as: export ZERO_BUILD=true . jdk/make/jdk_generic_profile.sh gmake sanity && gmake The mandatory environment variable does the following: ZERO_BUILD Setting ZERO_BUILD to "true" will cause the Zero interpreter to be used. If ZERO_BUILD is unset, or set to any other value than "true", the standard, platform-specific interpreter will be used. Of the other environment variables the following are required when ZERO_BUILD is set to "true". These are set by jdk/make/jdk_generic_profile.sh based on the result of uname -m: ZERO_LIBARCH This is the name of the architecture-specific subdirectory under $JAVA_HOME/jre/lib. Typically this will be the same as the output of uname -m, although there are some exceptions: "amd64" instead of "x86_64", for example, and "i386" instead of "i686". ZERO_ARCHDEF The value of ZERO_ARCHDEF will be passed to the C++ compiler using -D${ZERO_ARCHDEF} to allow conditionalized platform-specific code. This is typically set to ZERO_LIBARCH converted to uppercase but, again, there are exceptions. "i386" becomes "IA32", to match what HotSpot already does, and on platforms with both 32- and 64-bit variants ZERO_ARCHDEF corresponds to the 32-bit version, so both ppc and ppc64 have ZERO_ARCHDEF set to "PPC". ZERO_ENDIANNESS This is set to "little" or "big". ARCH_DATA_MODEL This is set to "32" or "64". ZERO_ARCHFLAG This is a flag that will be passed to the C++ compiler and to the linker to instruct them to generate code for the particular platform. This is required for platforms with both 32- and 64-bit variants where the compiler needs to be told which variant to build for. ZERO_ARCHFLAG will typically be set to "-m32" or "-m64", except on 31-bit zSeries where it will be set to "-m31". Zero uses one external library, libffi, for JNI method invocation. The following two variables are used to tell the compiler and linker how to find libffi. These can be set by the user, but if left unset then jdk/make/jdk_generic_profile.sh will attempt to set them using pkg-config or, failing that, by supplying defaults pointing to the standard locations: LIBFFI_CFLAGS Flags to be passed to the C++ compiler to build against libffi. If unset (and pkg-config is not installed, or if libffi is not built with pkg-config) then this defaults to "". LIBFFI_LIBS Flags to be passed to the linker to link against libffi. If unset (and pkg-config is not installed, or if libffi is not built with pkg-config) then this defaults to "-lffi". -- http://gbenson.net/ From karen.kinnear at sun.com Thu Sep 24 06:20:12 2009 From: karen.kinnear at sun.com (karen.kinnear at sun.com) Date: Thu, 24 Sep 2009 13:20:12 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20090924132018.683BE1286F@hg.openjdk.java.net> Changeset: 74a5db69c1fe Author: dcubed Date: 2009-09-21 09:30 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/74a5db69c1fe 6419370: 4/4 new jmethodID code has tiny holes in synchronization Summary: Fix races in jmethodID cache and JNI itable index cache. Reviewed-by: ikrylov, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.hpp Changeset: d72ba3205918 Author: acorn Date: 2009-09-21 18:10 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d72ba3205918 Merge Changeset: 87770dcf831b Author: dcubed Date: 2009-09-22 21:12 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/87770dcf831b 6876794: 4/4 sp07t002 hangs very intermittently Summary: remove over locking by VMThread on "is thread suspended?" check Reviewed-by: dholmes, acorn, andrew ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp From Daniel.Daugherty at Sun.COM Thu Sep 24 14:43:20 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Thu, 24 Sep 2009 15:43:20 -0600 Subject: Request for reviews (M): 6580131: Exposing Method Inlining InformationTo JVMTI Agents In-Reply-To: <7E25251AA9AC1F47937B3C615B77ADA86A00D3@SAUSEXMB2.amd.com> References: <7E25251AA9AC1F47937B3C615B77ADA86A00D3@SAUSEXMB2.amd.com> Message-ID: <4ABBE7F8.6030904@sun.com> Vasanth, Sorry it has taken me so long to get to this review. - is this targeted at OpenJDK6 or OpenJDK7? - original notes says needs 64-bit testing; still true? - will this need CCC approval? I hope not since this is a VM specific data stream that we're exporting. However ... - need to check with Kelly/Tim to see the right way to get the header file exported in the JDK. - the samples need some cleanup, but that's a side issue; they could be used as the basis for some new tests. src/share/vm/code/jvmticmlr.h > struct JvmtiCompiledMethodLoadRecordHeader_s - the "_s" suffix is not same style as JVM/TI; JVM/TI style is typedef struct _foo foo. - the "next" field is bothering me due to it making the data stream difficult to copy and relocate, but regular JVM/TI does pointers in returned data structures also. - version info should be explicit rather than bundled in "type" field - need to add version info constants, perhaps a major and minor number > struct JvmtiCompiledMethodLoadInlineRecord_s - The header field comment makes things a little more clear about the layout of this data. I'm thinking that the "void *" points to a blob of memory that we cast to: - JvmtiCompiledMethodLoadRecordHeader * which tells us the "type" of this record and tells us where the next record is or NULL. - JvmtiCompiledMethodLoadInlineRecord * which allows us to decode this first record - the "methods" and "bcis" fields possibly point to data that immediately follows the JvmtiCompiledMethodLoadInlineRecord; could be that all of the methods arrays and all of the bcis arrays are together in one place rather than interleaved Update: now that I've gone back and read the original e-mail, it is much more clear, but should some of this info be in the header file? > struct JvmtiCompiledMethodLoadDummyRecord_s - header comment mentions JvmtiCompiledMethodLoadRecord, but that does not exist src/share/vm/prims/jvmtiExport.cpp > line 1737 > int numstackframes = 0; This should be a "jint" just to match types. > line 1743 > "Assertion violation in add_inline_records:pc_address must be non-null" Drop the "Assertion violation in add_inline_records:" part; we know it's an assertion failure, the system will tell us where it is and the function name is wrong. > line 1753 > record->numstackframes = 0; You've already counted the frames by looping on 1748-1749. Why not set that value here rather than count again? If you're thinking that the ScopeDesc list size can change, then you need to check for an overflow in the loop on line 1755. > line 1754 > "Assertion violation in jvmtiExport::add_inline_records: numstackframes must be nonzero." Drop the "Assertion violation in jvmtiExport::add_inline_records:" part > line 1756 > record->methods[record->numstackframes] = sd->method()->jmethod_id(); This code does not check for a NULL method() return, but the code that calls this function does. I'm guessing that means that it is possible for sd->method() to return NULL here... Dan Venkatachalam, Vasanth wrote: > > Hi Tom, > > Thank you again for your detailed and insightful review. We have > revised our implementation based on your suggestions and submitted new > diffs for bugid 100085 with the changes described below. We have > attached these diffs and new sample JVMTI agents to the bug report at: > > > > https://bugs.openjdk.java.net/show_bug.cgi?id=100085 > > > > > > 1. Overall Structure > > > We have added one new header file to the Hotspot JVM, jvmticmlr.h. > This header defines a struct JvmtiCompiledMethodLoadRecordHeader that > represents arbitrary information passed through the void pointer. The > struct has a type field to indicate the type of information being > passed, and a next pointer. The type field can also be used to capture > versioning information. > > > > We also defined another struct, JvmtiCompiledMethodLoadInlineRecord, > which contains the previous struct as the first member but in addition > has extra fields for storing inlining information. One can similarly > define additional structs to pass other kinds of information. As an > example, we've defined a struct JvmtiCompiledMethodLoadDummyRecord, > which contains a string "I am a dummy record." When the sample JVMTI > agents that we have provided encounter a record of this type, they > print the string contained in the dummy record. > > > > This new header file jvmticmlr.h lives in the Hotspot > src/share/vm/code directory. However, we envision that the JDK > installer would copy it to the JDK include/ directory to make this > file available to external JVMTI agents, in the same way that it makes > jni.h available. > > > When a CompiledMethodLoad event is generated for an nmethod, the void > pointer will contain a list of JvmtiCompiledMethodLoadInlineRecords. > Each record has a pc address which actually represents a range of pc > addresses between that JvmtiCompiledMethodLoadInlineRecord and the pc > address of the next one in the list. > > > > When the sample JVMTI agents we have provided detect a > CompiledMethodLoad event, they first cast the void pointer,of the > CompiledMethodLoad callback to a JvmtiCompiledMethodLoadRecordHeader > * list, and iterate over each of the records in the list, checking > its type and then casting the record to the appropriate subtype > (e.g., JvmtiCompiledMethodLoadInlineRecords) before deciding how to > process it. > > > 2. Code Changes > > > > The main code changes are to the jvmtiExport.cpp file, located in > src/share/vm/prims. We have defined a new global method, > create_inline_records which returns a list of records containing > inline information for a given nmethod. The post_compiled_method_load > method of JvmtiExport calls this method to retrieve the > inlining information and pass it rhrough the void pointer. > > > > In addition to these changes, we have made the following miscellaneous > changes that were requested: > > > > -We changed the date of the copyright notices in the new header files > to 2009. > -We have changed all function names to use lowercase with underscores. > -We replaced null checks of impossible conditions with assertions as > recommended. > -We removed the unused type and offset fields from the data structure > that was previously called InlineInfoRecord and is now called > JVMTICompiledMethodLoadInlineRecord. We renamed the jmethodID[] array > to methods and bytecodeindexes to bcis. > -We removed the PCDescriptorList class since it was redundant. > > -We modified our code to use resource allocation rather than C heap > allocations. Please see the create_inline_records method in > jvmtiExport.cpp. > -We modified jvmtiExport.cpp to set the _compile_info void pointer > inside the JvmtiCompiledMethodLoadEventMark constructor, rather than > setting this pointer in a separate method call. > > > > 3. Sample Agents > > The sample agents now use the jvmticmlr.h header file. For ease of > testing, we have copied this header file from the JVM > > src/share/vm/code directory into the c and cpp directories containing > the agents. However, as noted before, the JDK installer would ideally > copy this header file to the JDK /include directory, so that it can be > made available in the same way that jni.h is available. > > > Again, we thank you for your detailed feedback. Please let us know if > you have additional comments or questions > > > > Regards, > > > > Vasanth > > > > > > *From:* Venkatachalam, Vasanth > *Sent:* Tuesday, August 04, 2009 10:47 AM > *To:* 'hotspot-dev at openjdk.java.net' > *Cc:* 'Thomas.Rodriguez at sun.com'; Joshi, Shrinivas; Pollan, Ben > *Subject:* RE: Request for reviews (M): 6580131: Exposing Method > Inlining InformationTo JVMTI Agents > > > > Hi Tom, > > > > Thank you for your detailed and insightful feedback on my JVMTI method > inlining submission. Sorry for the delay in responding to your > comments. We are scoping out the changes that you have recommended. > Some of these changes could take longer, but we hope to be able to > respond in a few days with some changes or at least a timeline on when > we can get them in. > > > > Regards, > > > > Vasanth > > > > > > -- > > Vasanth Venkatachalam > > AMD Java Labs > > (512)602-6177 > > > From andrey.petrusenko at sun.com Fri Sep 25 07:30:08 2009 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Fri, 25 Sep 2009 14:30:08 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20090925143016.BCD491290C@hg.openjdk.java.net> Changeset: c3c4a1d3801a Author: andrew Date: 2009-09-23 11:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c3c4a1d3801a 6884552: remove some unnecessary #ifdef's introduced in the fix for 4957990 Summary: Removed the unnecessary #ifdef's which were interfering with the build of the Zero-assembler port Reviewed-by: ysr, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp Changeset: 1af62b6ca0f9 Author: apetrusenko Date: 2009-09-25 04:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1af62b6ca0f9 Merge From Vasanth.Venkatachalam at amd.com Fri Sep 25 09:14:55 2009 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Fri, 25 Sep 2009 11:14:55 -0500 Subject: Request for reviews (M): 6580131: Exposing Method Inlining InformationTo JVMTI Agents In-Reply-To: <4ABBE7F8.6030904@sun.com> References: <7E25251AA9AC1F47937B3C615B77ADA86A00D3@SAUSEXMB2.amd.com> <4ABBE7F8.6030904@sun.com> Message-ID: Hi Dan, Thank you for your detailed feedback. We are scoping out the issues you have raised. We expect to be able to respond to your questions over the next few days. Regards, Vasanth -----Original Message----- From: Daniel.Daugherty at Sun.COM [mailto:Daniel.Daugherty at Sun.COM] Sent: Thursday, September 24, 2009 4:43 PM To: Venkatachalam, Vasanth Cc: hotspot-dev at openjdk.java.net; Pollan, Ben; Thomas.Rodriguez at Sun.COM Subject: Re: Request for reviews (M): 6580131: Exposing Method Inlining InformationTo JVMTI Agents Vasanth, Sorry it has taken me so long to get to this review. - is this targeted at OpenJDK6 or OpenJDK7? - original notes says needs 64-bit testing; still true? - will this need CCC approval? I hope not since this is a VM specific data stream that we're exporting. However ... - need to check with Kelly/Tim to see the right way to get the header file exported in the JDK. - the samples need some cleanup, but that's a side issue; they could be used as the basis for some new tests. src/share/vm/code/jvmticmlr.h > struct JvmtiCompiledMethodLoadRecordHeader_s - the "_s" suffix is not same style as JVM/TI; JVM/TI style is typedef struct _foo foo. - the "next" field is bothering me due to it making the data stream difficult to copy and relocate, but regular JVM/TI does pointers in returned data structures also. - version info should be explicit rather than bundled in "type" field - need to add version info constants, perhaps a major and minor number > struct JvmtiCompiledMethodLoadInlineRecord_s - The header field comment makes things a little more clear about the layout of this data. I'm thinking that the "void *" points to a blob of memory that we cast to: - JvmtiCompiledMethodLoadRecordHeader * which tells us the "type" of this record and tells us where the next record is or NULL. - JvmtiCompiledMethodLoadInlineRecord * which allows us to decode this first record - the "methods" and "bcis" fields possibly point to data that immediately follows the JvmtiCompiledMethodLoadInlineRecord; could be that all of the methods arrays and all of the bcis arrays are together in one place rather than interleaved Update: now that I've gone back and read the original e-mail, it is much more clear, but should some of this info be in the header file? > struct JvmtiCompiledMethodLoadDummyRecord_s - header comment mentions JvmtiCompiledMethodLoadRecord, but that does not exist src/share/vm/prims/jvmtiExport.cpp > line 1737 > int numstackframes = 0; This should be a "jint" just to match types. > line 1743 > "Assertion violation in add_inline_records:pc_address must be non-null" Drop the "Assertion violation in add_inline_records:" part; we know it's an assertion failure, the system will tell us where it is and the function name is wrong. > line 1753 > record->numstackframes = 0; You've already counted the frames by looping on 1748-1749. Why not set that value here rather than count again? If you're thinking that the ScopeDesc list size can change, then you need to check for an overflow in the loop on line 1755. > line 1754 > "Assertion violation in jvmtiExport::add_inline_records: numstackframes must be nonzero." Drop the "Assertion violation in jvmtiExport::add_inline_records:" part > line 1756 > record->methods[record->numstackframes] = sd->method()->jmethod_id(); This code does not check for a NULL method() return, but the code that calls this function does. I'm guessing that means that it is possible for sd->method() to return NULL here... Dan Venkatachalam, Vasanth wrote: > > Hi Tom, > > Thank you again for your detailed and insightful review. We have > revised our implementation based on your suggestions and submitted new > diffs for bugid 100085 with the changes described below. We have > attached these diffs and new sample JVMTI agents to the bug report at: > > > > https://bugs.openjdk.java.net/show_bug.cgi?id=100085 > > > > > > 1. Overall Structure > > > We have added one new header file to the Hotspot JVM, jvmticmlr.h. > This header defines a struct JvmtiCompiledMethodLoadRecordHeader that > represents arbitrary information passed through the void pointer. The > struct has a type field to indicate the type of information being > passed, and a next pointer. The type field can also be used to capture > versioning information. > > > > We also defined another struct, JvmtiCompiledMethodLoadInlineRecord, > which contains the previous struct as the first member but in addition > has extra fields for storing inlining information. One can similarly > define additional structs to pass other kinds of information. As an > example, we've defined a struct JvmtiCompiledMethodLoadDummyRecord, > which contains a string "I am a dummy record." When the sample JVMTI > agents that we have provided encounter a record of this type, they > print the string contained in the dummy record. > > > > This new header file jvmticmlr.h lives in the Hotspot > src/share/vm/code directory. However, we envision that the JDK > installer would copy it to the JDK include/ directory to make this > file available to external JVMTI agents, in the same way that it makes > jni.h available. > > > When a CompiledMethodLoad event is generated for an nmethod, the void > pointer will contain a list of JvmtiCompiledMethodLoadInlineRecords. > Each record has a pc address which actually represents a range of pc > addresses between that JvmtiCompiledMethodLoadInlineRecord and the pc > address of the next one in the list. > > > > When the sample JVMTI agents we have provided detect a > CompiledMethodLoad event, they first cast the void pointer,of the > CompiledMethodLoad callback to a JvmtiCompiledMethodLoadRecordHeader > * list, and iterate over each of the records in the list, checking > its type and then casting the record to the appropriate subtype > (e.g., JvmtiCompiledMethodLoadInlineRecords) before deciding how to > process it. > > > 2. Code Changes > > > > The main code changes are to the jvmtiExport.cpp file, located in > src/share/vm/prims. We have defined a new global method, > create_inline_records which returns a list of records containing > inline information for a given nmethod. The post_compiled_method_load > method of JvmtiExport calls this method to retrieve the > inlining information and pass it rhrough the void pointer. > > > > In addition to these changes, we have made the following miscellaneous > changes that were requested: > > > > -We changed the date of the copyright notices in the new header files > to 2009. > -We have changed all function names to use lowercase with underscores. > -We replaced null checks of impossible conditions with assertions as > recommended. > -We removed the unused type and offset fields from the data structure > that was previously called InlineInfoRecord and is now called > JVMTICompiledMethodLoadInlineRecord. We renamed the jmethodID[] array > to methods and bytecodeindexes to bcis. > -We removed the PCDescriptorList class since it was redundant. > > -We modified our code to use resource allocation rather than C heap > allocations. Please see the create_inline_records method in > jvmtiExport.cpp. > -We modified jvmtiExport.cpp to set the _compile_info void pointer > inside the JvmtiCompiledMethodLoadEventMark constructor, rather than > setting this pointer in a separate method call. > > > > 3. Sample Agents > > The sample agents now use the jvmticmlr.h header file. For ease of > testing, we have copied this header file from the JVM > > src/share/vm/code directory into the c and cpp directories containing > the agents. However, as noted before, the JDK installer would ideally > copy this header file to the JDK /include directory, so that it can be > made available in the same way that jni.h is available. > > > Again, we thank you for your detailed feedback. Please let us know if > you have additional comments or questions > > > > Regards, > > > > Vasanth > > > > > > *From:* Venkatachalam, Vasanth > *Sent:* Tuesday, August 04, 2009 10:47 AM > *To:* 'hotspot-dev at openjdk.java.net' > *Cc:* 'Thomas.Rodriguez at sun.com'; Joshi, Shrinivas; Pollan, Ben > *Subject:* RE: Request for reviews (M): 6580131: Exposing Method > Inlining InformationTo JVMTI Agents > > > > Hi Tom, > > > > Thank you for your detailed and insightful feedback on my JVMTI method > inlining submission. Sorry for the delay in responding to your > comments. We are scoping out the changes that you have recommended. > Some of these changes could take longer, but we hope to be able to > respond in a few days with some changes or at least a timeline on when > we can get them in. > > > > Regards, > > > > Vasanth > > > > > > -- > > Vasanth Venkatachalam > > AMD Java Labs > > (512)602-6177 > > > From vladimir.kozlov at sun.com Fri Sep 25 15:57:45 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 25 Sep 2009 22:57:45 +0000 Subject: hg: hsx/hsx16/baseline: 6883468: C2 compiler enters infinite loop in PhaseIterGVN::transform Message-ID: <20090925225751.2651A12986@hg.openjdk.java.net> Changeset: 2c0279a08300 Author: kvn Date: 2009-09-25 13:21 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/2c0279a08300 6883468: C2 compiler enters infinite loop in PhaseIterGVN::transform Summary: Avoid ideal transformation ping-pong between AddPNode::Ideal() and CastX2PNode::Ideal(). Reviewed-by: cfang ! src/share/vm/opto/connode.cpp From gnu_andrew at member.fsf.org Mon Sep 28 14:02:28 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 28 Sep 2009 22:02:28 +0100 Subject: DeoptimizeALot JTreg tests Message-ID: <17c6771e0909281402t33a9cf6bm7f5cf634d3ae94e@mail.gmail.com> There are two tests in OpenJDK7: compiler/6823453/Test.java : DeoptimizeALot causes fastdebug server jvm to fail with assert(false,"unscheduable graph") compiler/6833129/Test.java : Object.clone() and Arrays.copyOf ignore coping with -XX:+DeoptimizeALot that fail due to the absence of +DeoptimizeALot on a product build and prevent a clean run from being achieved. Is there not some way these tests can be automatically skipped if they are inapplicable to the build being tested? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Vladimir.Kozlov at Sun.COM Mon Sep 28 14:06:53 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 28 Sep 2009 14:06:53 -0700 Subject: DeoptimizeALot JTreg tests In-Reply-To: <17c6771e0909281402t33a9cf6bm7f5cf634d3ae94e@mail.gmail.com> References: <17c6771e0909281402t33a9cf6bm7f5cf634d3ae94e@mail.gmail.com> Message-ID: <4AC1256D.6020501@sun.com> You can use flag -XX:+IgnoreUnrecognizedVMOptions with these tests. Vladimir Andrew John Hughes wrote: > There are two tests in OpenJDK7: > > compiler/6823453/Test.java : DeoptimizeALot causes fastdebug server > jvm to fail with assert(false,"unscheduable graph") > compiler/6833129/Test.java : Object.clone() and Arrays.copyOf ignore > coping with -XX:+DeoptimizeALot > > that fail due to the absence of +DeoptimizeALot on a product build and > prevent a clean run from being achieved. Is there not some way these > tests can be automatically skipped if they are inapplicable to the > build being tested? From Thomas.Rodriguez at Sun.COM Mon Sep 28 14:14:43 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 28 Sep 2009 14:14:43 -0700 Subject: DeoptimizeALot JTreg tests In-Reply-To: <4AC1256D.6020501@sun.com> References: <17c6771e0909281402t33a9cf6bm7f5cf634d3ae94e@mail.gmail.com> <4AC1256D.6020501@sun.com> Message-ID: <4AE15289-843C-4F1E-9ED9-3FBE5DCE0A62@sun.com> We should go ahead and add that to the tests as we've done for others. tom On Sep 28, 2009, at 2:06 PM, Vladimir Kozlov wrote: > You can use flag -XX:+IgnoreUnrecognizedVMOptions with these tests. > > Vladimir > > Andrew John Hughes wrote: >> There are two tests in OpenJDK7: >> compiler/6823453/Test.java : DeoptimizeALot causes fastdebug server >> jvm to fail with assert(false,"unscheduable graph") >> compiler/6833129/Test.java : Object.clone() and Arrays.copyOf ignore >> coping with -XX:+DeoptimizeALot >> that fail due to the absence of +DeoptimizeALot on a product build >> and >> prevent a clean run from being achieved. Is there not some way these >> tests can be automatically skipped if they are inapplicable to the >> build being tested? From gnu_andrew at member.fsf.org Mon Sep 28 15:08:03 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 28 Sep 2009 23:08:03 +0100 Subject: DeoptimizeALot JTreg tests In-Reply-To: <4AE15289-843C-4F1E-9ED9-3FBE5DCE0A62@sun.com> References: <17c6771e0909281402t33a9cf6bm7f5cf634d3ae94e@mail.gmail.com> <4AC1256D.6020501@sun.com> <4AE15289-843C-4F1E-9ED9-3FBE5DCE0A62@sun.com> Message-ID: <17c6771e0909281508j2cfbb2d6i1e8323eeb8192acc@mail.gmail.com> 2009/9/28 Tom Rodriguez : > We should go ahead and add that to the tests as we've done for others. > > tom > > On Sep 28, 2009, at 2:06 PM, Vladimir Kozlov wrote: > >> You can use flag -XX:+IgnoreUnrecognizedVMOptions with these tests. >> >> Vladimir >> >> Andrew John Hughes wrote: >>> >>> There are two tests in OpenJDK7: >>> compiler/6823453/Test.java : DeoptimizeALot causes fastdebug server >>> jvm to fail with assert(false,"unscheduable graph") >>> compiler/6833129/Test.java : Object.clone() and Arrays.copyOf ignore >>> coping with -XX:+DeoptimizeALot >>> that fail due to the absence of +DeoptimizeALot on a product build and >>> prevent a clean run from being achieved. ?Is there not some way these >>> tests can be automatically skipped if they are inapplicable to the >>> build being tested? > > Like this? http://cr.openjdk.java.net/~andrew/hotspot/webrev.03/ If that looks ok, please assign it a bug ID and submit it to JPRT. Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Changpeng.Fang at Sun.COM Mon Sep 28 16:01:22 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Mon, 28 Sep 2009 16:01:22 -0700 Subject: DeoptimizeALot JTreg tests In-Reply-To: <17c6771e0909281508j2cfbb2d6i1e8323eeb8192acc@mail.gmail.com> References: <17c6771e0909281402t33a9cf6bm7f5cf634d3ae94e@mail.gmail.com> <4AC1256D.6020501@sun.com> <4AE15289-843C-4F1E-9ED9-3FBE5DCE0A62@sun.com> <17c6771e0909281508j2cfbb2d6i1e8323eeb8192acc@mail.gmail.com> Message-ID: <4AC14042.6070200@sun.com> I am going to do this (and take a look whether there anything similar to this case). Thanks, Changpeng On 09/28/09 15:08, Andrew John Hughes wrote: > 2009/9/28 Tom Rodriguez : > >> We should go ahead and add that to the tests as we've done for others. >> >> tom >> >> On Sep 28, 2009, at 2:06 PM, Vladimir Kozlov wrote: >> >> >>> You can use flag -XX:+IgnoreUnrecognizedVMOptions with these tests. >>> >>> Vladimir >>> >>> Andrew John Hughes wrote: >>> >>>> There are two tests in OpenJDK7: >>>> compiler/6823453/Test.java : DeoptimizeALot causes fastdebug server >>>> jvm to fail with assert(false,"unscheduable graph") >>>> compiler/6833129/Test.java : Object.clone() and Arrays.copyOf ignore >>>> coping with -XX:+DeoptimizeALot >>>> that fail due to the absence of +DeoptimizeALot on a product build and >>>> prevent a clean run from being achieved. Is there not some way these >>>> tests can be automatically skipped if they are inapplicable to the >>>> build being tested? >>>> >> > > Like this? > > http://cr.openjdk.java.net/~andrew/hotspot/webrev.03/ > > If that looks ok, please assign it a bug ID and submit it to JPRT. > > Thanks, > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090928/2bc2e432/attachment.html From gnu_andrew at member.fsf.org Tue Sep 29 12:55:56 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 29 Sep 2009 20:55:56 +0100 Subject: DeoptimizeALot JTreg tests In-Reply-To: <4AC14042.6070200@sun.com> References: <17c6771e0909281402t33a9cf6bm7f5cf634d3ae94e@mail.gmail.com> <4AC1256D.6020501@sun.com> <4AE15289-843C-4F1E-9ED9-3FBE5DCE0A62@sun.com> <17c6771e0909281508j2cfbb2d6i1e8323eeb8192acc@mail.gmail.com> <4AC14042.6070200@sun.com> Message-ID: <17c6771e0909291255w43b79163k242789c31b844796@mail.gmail.com> 2009/9/29 Changpeng Fang : > I am going to do this (and take a look whether there anything similar to > this case). > > Thanks, > > Changpeng > > > On 09/28/09 15:08, Andrew John Hughes wrote: > > 2009/9/28 Tom Rodriguez : > > > We should go ahead and add that to the tests as we've done for others. > > tom > > On Sep 28, 2009, at 2:06 PM, Vladimir Kozlov wrote: > > > > You can use flag -XX:+IgnoreUnrecognizedVMOptions with these tests. > > Vladimir > > Andrew John Hughes wrote: > > > There are two tests in OpenJDK7: > compiler/6823453/Test.java : DeoptimizeALot causes fastdebug server > jvm to fail with assert(false,"unscheduable graph") > compiler/6833129/Test.java : Object.clone() and Arrays.copyOf ignore > coping with -XX:+DeoptimizeALot > that fail due to the absence of +DeoptimizeALot on a product build and > prevent a clean run from being achieved. ?Is there not some way these > tests can be automatically skipped if they are inapplicable to the > build being tested? > > > > > Like this? > > http://cr.openjdk.java.net/~andrew/hotspot/webrev.03/ > > If that looks ok, please assign it a bug ID and submit it to JPRT. > > Thanks, > > Why have you rewritten this patch and given me no credit for it? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Changpeng.Fang at Sun.COM Tue Sep 29 13:21:41 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Tue, 29 Sep 2009 13:21:41 -0700 Subject: DeoptimizeALot JTreg tests In-Reply-To: <17c6771e0909291255w43b79163k242789c31b844796@mail.gmail.com> References: <17c6771e0909281402t33a9cf6bm7f5cf634d3ae94e@mail.gmail.com> <4AC1256D.6020501@sun.com> <4AE15289-843C-4F1E-9ED9-3FBE5DCE0A62@sun.com> <17c6771e0909281508j2cfbb2d6i1e8323eeb8192acc@mail.gmail.com> <4AC14042.6070200@sun.com> <17c6771e0909291255w43b79163k242789c31b844796@mail.gmail.com> Message-ID: <4AC26C55.8090608@sun.com> I am doing to add in the bug report that the patch was actually contributed by Andrew John Hughes . Thanks, Changpeng >> >> Like this? >> >> http://cr.openjdk.java.net/~andrew/hotspot/webrev.03/ >> >> If that looks ok, please assign it a bug ID and submit it to JPRT. >> >> Thanks, >> >> >> > > Why have you rewritten this patch and given me no credit for it? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090929/e662a702/attachment.html From gnu_andrew at member.fsf.org Tue Sep 29 13:47:58 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 29 Sep 2009 21:47:58 +0100 Subject: DeoptimizeALot JTreg tests In-Reply-To: <4AC26C55.8090608@sun.com> References: <17c6771e0909281402t33a9cf6bm7f5cf634d3ae94e@mail.gmail.com> <4AC1256D.6020501@sun.com> <4AE15289-843C-4F1E-9ED9-3FBE5DCE0A62@sun.com> <17c6771e0909281508j2cfbb2d6i1e8323eeb8192acc@mail.gmail.com> <4AC14042.6070200@sun.com> <17c6771e0909291255w43b79163k242789c31b844796@mail.gmail.com> <4AC26C55.8090608@sun.com> Message-ID: <17c6771e0909291347t6fb6b250l6405656209d7f9f6@mail.gmail.com> 2009/9/29 Changpeng Fang : > I am doing to add in the bug report that the patch was actually contributed > by > Andrew John Hughes . > Ok. The usual method seems to be to use my uid as the changeset author for JPRT pushes (at least that was the case with the last two). Note that the comment accepts a 'Contributed-by' line too. > Thanks, > > Changpeng > > Like this? > > http://cr.openjdk.java.net/~andrew/hotspot/webrev.03/ > > If that looks ok, please assign it a bug ID and submit it to JPRT. > > Thanks, > > > > > Why have you rewritten this patch and given me no credit for it? > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Changpeng.Fang at Sun.COM Tue Sep 29 14:36:50 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Tue, 29 Sep 2009 14:36:50 -0700 Subject: DeoptimizeALot JTreg tests In-Reply-To: <17c6771e0909291347t6fb6b250l6405656209d7f9f6@mail.gmail.com> References: <17c6771e0909281402t33a9cf6bm7f5cf634d3ae94e@mail.gmail.com> <4AC1256D.6020501@sun.com> <4AE15289-843C-4F1E-9ED9-3FBE5DCE0A62@sun.com> <17c6771e0909281508j2cfbb2d6i1e8323eeb8192acc@mail.gmail.com> <4AC14042.6070200@sun.com> <17c6771e0909291255w43b79163k242789c31b844796@mail.gmail.com> <4AC26C55.8090608@sun.com> <17c6771e0909291347t6fb6b250l6405656209d7f9f6@mail.gmail.com> Message-ID: <4AC27DF2.2030402@sun.com> On 09/29/09 13:47, Andrew John Hughes wrote: > 2009/9/29 Changpeng Fang : > >> I am doing to add in the bug report that the patch was actually contributed >> by >> Andrew John Hughes . >> >> > > Ok. The usual method seems to be to use my uid as the changeset > author for JPRT pushes (at least that was the case with the last two). > Note that the comment accepts a 'Contributed-by' line too. > > Thanks for reminding me. And thank Vladimir for suggesting the solution. Changpeng >> Thanks, >> >> Changpeng >> >> Like this? >> >> http://cr.openjdk.java.net/~andrew/hotspot/webrev.03/ >> >> If that looks ok, please assign it a bug ID and submit it to JPRT. >> >> Thanks, >> >> >> >> >> Why have you rewritten this patch and given me no credit for it? >> >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090929/e70cd27a/attachment-0001.html From volker.simonis at gmail.com Wed Sep 30 10:05:58 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 30 Sep 2009 19:05:58 +0200 Subject: Improper usage of CHECK macros generates unreachable code Message-ID: Hi, in src/share/vm/utilities/exceptions.hpp some helper macros get defined as follows: #define CHECK THREAD); if (HAS_PENDING_EXCEPTION) return ; (0 #define CHECK_(result) THREAD); if (HAS_PENDING_EXCEPTION) return result; (0 #define CHECK_0 CHECK_(0) #define CHECK_NH CHECK_(Handle()) #define CHECK_NULL CHECK_(NULL) #define CHECK_false CHECK_(false) They are intended to simplify the calling of methods which require a THREAD reference and which can potentially raise an exception. A typical use case is the following (taken from 'klass.cpp'): Klass* kl = (Klass*) vtbl.allocate_permanent(klass, size, CHECK_NULL); klassOop k = kl->as_klassOop(); which will be macro expanded into: Klass* kl = (Klass*) vtbl.allocate_permanent(klass, size, THREAD); if (HAS_PENDING_EXCEPTION) return NULL; (0); klassOop k = kl->as_klassOop(); This use case is reasonable and fine. However there are a lot of places in the Hotspot, where the check macros are used as follows (taken from 'perfData.hpp'): static PerfStringVariable* create_string_variable(CounterNS ns, const char* name, const char *s, TRAPS) { return create_string_variable(ns, name, 0, s, CHECK_NULL); }; This will expand into: static PerfStringVariable* create_string_variable(CounterNS ns, const char* name, const char *s, TRAPS) { return create_string_variable(ns, name, 0, s, THREAD); if (HAS_PENDING_EXCEPTION) return NULL; (0); }; which contains unreachable code after the return statement. Now this is not only a problem of an omitted check for a pending exception (which is probably not so problematic here because the function returns anyway) but more a problem with modern compilers which issue a warning here because of unreachable code. And because this wrong usage pattern of the CHECK macros is spread across several include files (e.g. constantPoolOop.hpp, oopFactory.hpp, typeArrayKlass.hpp, perfData.hpp, synchronizer.hpp) we get A LOT of warnings for nearly every compilation unit. I would therefore suggest to replace such "wrong" usages of the CHECK macros with simple THREAD macros. If somebody feels that the checks for pending exceptions are really necessary in some places, we should use a local variable to save the return value of the function call and return that variable in the next statement. If somebody would be so kind to open a bug for this issue, I would contribute a patch which fixes the mentioned 'misuses' of the CHECK macro. Regrards, Volker From thomas.rodriguez at sun.com Wed Sep 30 14:32:49 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Wed, 30 Sep 2009 21:32:49 +0000 Subject: hg: hsx/hsx16/baseline: 6855215: Calculation error (NaN) after about 1500 calculations Message-ID: <20090930213252.BE5A441616@hg.openjdk.java.net> Changeset: d19a5a05d449 Author: never Date: 2009-09-30 11:57 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/d19a5a05d449 6855215: Calculation error (NaN) after about 1500 calculations Reviewed-by: kvn ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp + test/compiler/6855215/Test6855215.java From Thomas.Rodriguez at Sun.COM Wed Sep 30 14:57:51 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 30 Sep 2009 14:57:51 -0700 Subject: Second Zero review request In-Reply-To: <20090924125631.GD3292@redhat.com> References: <20090924125631.GD3292@redhat.com> Message-ID: <604C5161-8E04-45EA-A093-A7D7EFBEFDA3@sun.com> I'm looking through these changes right now but I finally looked into getting the arch into the build directory name. Basically I added an extra variable called VARIANTARCH that is used to override BUILDARCH in PLATFORM_DIR and modified the zero build rules to use ZERO_LIBARCH for this. This results in linux_i386_zero for example, so it won't use the same arch names as regular hotspot builds since they use i486 for historical reasons but it's a more accurate naming than zero_zero. I also found that I couldn't build zero by simply cd'ing to make/linux and type make jvmgzero (plus all the required ZERO_ defs) as I would expect. The reason is that the code that generates platform_zero refers to OUTPUTDIR which doesn't mean anything unless you invoke make from make/Makefile. It has a value but that value isn't the necessarily the actual output directory. The platform makefiles always build in the current directory so simply removing $(OUTPUTDIR) for that platform_zero rule allows it to work as expected and shouldn't change it's behaviour since OUTPUTDIR is always equivalent to pwd. I've attached a patch that does both the VARIANTARCH changes and the platform_zero changes. I was able to build successfully with both make/Makefile and make/linux/Makefile producing linux_i386_zero as the build directory. You might consider making the generated platform file be platform_zero_$(ZERO_LIBARCH) instead of just the bare platform_zero. Unfortunately the bits crashed when running Queens but that happened with or without my changes. The make command I issued was: make ZERO_ARCHDEF=IA32 ZERO_BUILD=true ZERO_LIBARCH=i386 ZERO_ENDIANNESS=little ARCH_DATA_MODEL=32 ZERO_ARCHFLAG=-m32 jvmgzero LIBFFI_LIBS=-lffi This is the crash message. cd linux_i386_zero/jvmg && ./test_gamma java full version "1.6.0_14-b08" # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/ bytecodeInterpreter.cpp:427 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/never/hotspot/src/share/vm/interpreter/ bytecodeInterpreter.cpp:427), pid=9886, tid=1082800448 # Error: assert(istate->_stack_limit == istate->_thread- >last_Java_sp() + 1,"wrong") # # JRE version: 6.0_14-b08 # Java VM: OpenJDK Zero VM (17.0-b01-internal-jvmg interpreted mode linux-i386 ) # An error report file with more information is saved as: # /home/never/hotspot/make/linux/linux_i386_zero/jvmg/hs_err_pid9886.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Current thread is 1082800448 Dumping core ... Aborted make: *** [jvmgzero] Error 134 I can provide more details if that's useful. tom -------------- next part -------------- A non-text attachment was scrubbed... Name: bp.patch Type: application/octet-stream Size: 2816 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090930/674ba492/attachment.obj -------------- next part -------------- On Sep 24, 2009, at 5:56 AM, Gary Benson wrote: > Hi all, > > Zero is an interpreter-only port of HotSpot that uses no assembler and > can trivially be built on any Linux system. The following webrev adds > Zero support to OpenJDK: > > http://cr.openjdk.java.net/~gbenson/zero-10/ > > Building is largely the same as the previous webrev (zero-07) except > for the following changes: > > - The variable CORE_BUILD is no longer used. > - The variable ZERO_BITSPERWORD has been replaced with > ARCH_DATA_MODEL > > Summary of changes > ================== > > - The code has been reformatted to better match HotSpot's coding > conventions. Notably, all opening braces have been moved to the > end of the previous line, rather than being on their own lines. > > - The variable CORE_BUILD is no longer required. Setting ZERO_BUILD > is all that is required to enable Zero. > > - The Zero build process no longer hijacks the core rules in the > makefiles, but provides its own rules. A consequence of this is > that the build directory is now linux_zero_zero rather than > linux_zero_core. Another consequence is that Zero now has its > own includeDB file, into which all direct #includes have been > moved. > > - The variable ZERO_BITSPERWORD has been replaced with the existing > ARCH_DATA_MODEL. > > - The type definition ZeroEntry::method_entry_t has been renamed. > Tom Rodriguez suggested MethodEntryFunc, but Zero now supports > OSR, which requires a different calling convention, so there is > now ZeroEntry::NormalEntryFunc and ZeroEntry::OSREntryFunc. > > - Zero no longer hijacks C2_BASE_DIR in hotspot/make/Makefile. > ZERO_BASE_DIR is used instead. > > - A duplicate definition of STATIC_CXX was removed. > > - Zero's ICache now overrides some AbstractICache methods with > empty methods, avoiding conditionals in icache.cpp. Comments > in icache_zero.hpp explain this rationale. > > - JNIHandles::clear is now protected on all platforms, not just Zero. > > - Code from the ZeroStackPrinter class has been migrated to methods > in ZeroFrame and its subclasses. stackPrinter_zero.hpp (previously > directly included from vmError.cpp) has been removed, and most of > the Zero-specific code in VMError::report has likewise been > replaced. There is still a small amount of conditional code in > VMError::report, but this could be removed entirely if it is not > acceptable (at the expense of losing the super-detailed stack > traces that Zero emits, eg http://tinyurl.com/y9rp4r3). > > - frame::frame uses find_blob_unsafe instead of find_blob. > > - All stubs contain ShouldNotCallThis() instead of Unimplemented(). > > Summary of non-changes > ====================== > > - The variable ZERO_ENDIANNESS remains unchanged. I haven't renamed > it as ENDIANNESS because it's only used during Zero builds. It's > possible that the makefiles could be refactored such that, for > example, existing platforms set ENDIANNESS (leaving Zero requiring > it to be set externally) but I wasn't sure I should be doing this > in this patch. > > - The build directory is linux_zero_zero (or linux_zero_shark) rather > than linux_$(ARCH)_zero. There is no variable defining the name of > the build directory as such, it's always referenced as > $(OSNAME)_$(BUILDARCH)_whatever, and in addition to specifiying the > build directory, BUILDARCH is used in conditionals in various > makefiles to add extra compiler flags, etc. If BUILDARCH is set to > "i486", for example, then extra compiler flags are added which are > unnecessary (and possibly problematic) for Zero. > > - The variable ZERO_LIBARCH remains. It's used in several different > places, and I couldn't figure out a place to put the logic to > convert a uname string to the correct ZERO_LIBARCH value where the > result would be accessible everywhere it is required. > > Build Instructions > ================== > > There are a number of environment variables that need setting before > running make, but if you are using jdk/make/jdk_generic_profile.sh > to set up your environment then you only need to set one, and a build > can be as simple as: > > export ZERO_BUILD=true > . jdk/make/jdk_generic_profile.sh > gmake sanity && gmake > > The mandatory environment variable does the following: > > ZERO_BUILD > Setting ZERO_BUILD to "true" will cause the Zero interpreter to > be used. If ZERO_BUILD is unset, or set to any other value than > "true", the standard, platform-specific interpreter will be used. > > Of the other environment variables the following are required when > ZERO_BUILD is set to "true". These are set by > jdk/make/jdk_generic_profile.sh based on the result of uname -m: > > ZERO_LIBARCH > This is the name of the architecture-specific subdirectory under > $JAVA_HOME/jre/lib. Typically this will be the same as the > output > of uname -m, although there are some exceptions: "amd64" instead > of "x86_64", for example, and "i386" instead of "i686". > > ZERO_ARCHDEF > The value of ZERO_ARCHDEF will be passed to the C++ compiler > using > -D${ZERO_ARCHDEF} to allow conditionalized platform-specific > code. > This is typically set to ZERO_LIBARCH converted to uppercase but, > again, there are exceptions. "i386" becomes "IA32", to match > what > HotSpot already does, and on platforms with both 32- and 64-bit > variants ZERO_ARCHDEF corresponds to the 32-bit version, so both > ppc and ppc64 have ZERO_ARCHDEF set to "PPC". > > ZERO_ENDIANNESS > This is set to "little" or "big". > > ARCH_DATA_MODEL > This is set to "32" or "64". > > ZERO_ARCHFLAG > This is a flag that will be passed to the C++ compiler and to the > linker to instruct them to generate code for the particular > platform. This is required for platforms with both 32- and 64- > bit > variants where the compiler needs to be told which variant to > build for. ZERO_ARCHFLAG will typically be set to "-m32" or > "-m64", except on 31-bit zSeries where it will be set to "-m31". > > Zero uses one external library, libffi, for JNI method invocation. > The following two variables are used to tell the compiler and linker > how to find libffi. These can be set by the user, but if left unset > then jdk/make/jdk_generic_profile.sh will attempt to set them using > pkg-config or, failing that, by supplying defaults pointing to the > standard locations: > > LIBFFI_CFLAGS > Flags to be passed to the C++ compiler to build against libffi. > If unset (and pkg-config is not installed, or if libffi is not > built with pkg-config) then this defaults to "". > > LIBFFI_LIBS > Flags to be passed to the linker to link against libffi. If > unset (and pkg-config is not installed, or if libffi is not > built with pkg-config) then this defaults to "-lffi". > > -- > http://gbenson.net/ From john.rose at sun.com Wed Sep 30 16:44:06 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Wed, 30 Sep 2009 23:44:06 +0000 Subject: hg: jdk7/hotspot/hotspot: 13 new changesets Message-ID: <20090930234446.1760E4163B@hg.openjdk.java.net> Changeset: 685e959d09ea Author: cfang Date: 2009-09-14 09:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/685e959d09ea 6877254: Server vm crashes with no branches off of store slice" when run with CMS and UseSuperWord(default) Summary: design StoreCMNode::Ideal to promote its oopStore input if the input is a MergeMem node Reviewed-by: kvn, never ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/superword.cpp + test/compiler/6877254/Test.java Changeset: 62001a362ce9 Author: kvn Date: 2009-09-14 12:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/62001a362ce9 6827605: new String intrinsics may prevent EA scalar replacement 6875866: Intrinsic for String.indexOf() is broken on x86 with SSE4.2 Summary: Modify String intrinsic methods to pass char[] pointers instead of string oops. Reviewed-by: never ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp + test/compiler/6875866/Test.java Changeset: 00977607da34 Author: cfang Date: 2009-09-15 11:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/00977607da34 6879921: CTW failure jdk6_18/hotspot/src/share/vm/utilities/globalDefinitions.cpp:268 Summary: filter out non-primitives before deciding whether two ops can be packed Reviewed-by: kvn, never ! src/share/vm/opto/superword.cpp Changeset: 7e309ecb83ce Author: kvn Date: 2009-09-15 19:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7e309ecb83ce 6879362: assert(!klass_is_exact(),"only non-exact klass") Summary: Do nothing for AddP node which has type not related to the type of allocated object. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: 148e5441d916 Author: jrose Date: 2009-09-15 21:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/148e5441d916 6863023: need non-perm oops in code cache for JSR 292 Summary: Make a special root-list for those few nmethods which might contain non-perm oops. Reviewed-by: twisti, kvn, never, jmasa, ysr ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_ValueType.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciObject.cpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! 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/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline2.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/utilities/debug.cpp Changeset: be094e0c089a Author: jrose Date: 2009-09-15 22:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/be094e0c089a Merge Changeset: 3a2aa26bdc58 Author: never Date: 2009-09-16 11:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3a2aa26bdc58 6854812: 6.0_14-b08 crashes with a SIGSEGV Reviewed-by: kvn, twisti ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/opto/parse1.cpp Changeset: 6a8ccac44f41 Author: kvn Date: 2009-09-18 09:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6a8ccac44f41 6820514: meet not symmetric failure in ctw Summary: Add missing instance_id meet. Reviewed-by: never ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: 54b3b351d6f9 Author: jrose Date: 2009-09-23 23:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/54b3b351d6f9 Merge ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! 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/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 753cf9794df9 Author: jrose Date: 2009-09-23 23:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/753cf9794df9 6885169: merge of 4957990 and 6863023 causes conflict on do_nmethods Summary: After mechanically merging changes, some by-hand adjustments are needed. Reviewed-by: ysr ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp Changeset: ddd6f1182ae3 Author: kvn Date: 2009-09-25 13:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ddd6f1182ae3 6883468: C2 compiler enters infinite loop in PhaseIterGVN::transform Summary: Avoid ideal transformation ping-pong between AddPNode::Ideal() and CastX2PNode::Ideal(). Reviewed-by: cfang ! src/share/vm/opto/connode.cpp Changeset: d6b9fd78f389 Author: cfang Date: 2009-09-28 17:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d6b9fd78f389 6886353: For DeoptimizeALot, JTreg tests should "IgnoreUnrecognizedVMOptions on a product build Summary: Add IgnoreUnrecognizedVMOptions for JTreg tests (on a product build) to pass with DeoptimizeALot Reviewed-by: kvn ! test/compiler/6823453/Test.java ! test/compiler/6833129/Test.java Changeset: 46b819ba120b Author: jrose Date: 2009-09-30 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/46b819ba120b Merge ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp