From janvanbesien at gmail.com Wed Feb 4 10:44:00 2009 From: janvanbesien at gmail.com (Jan Van Besien) Date: Wed, 04 Feb 2009 19:44:00 +0100 Subject: runtime dispatch between different versions of the same module Message-ID: <4989E1F0.5030408@gmail.com> Hi Jigsaw developers, I have a question: will the Jigsaw project allow me to dispatch at runtime between different versions of the same module? The language changes will allow me to specify that a module depends on another module with a certain version, but probably not on two versions of that other module at the same time, correct? Maybe the API will allow me to do it (with reflection?), but I was unable to be sure from the documentation currently available on the website. I have this use case currently in a project at work, and we solved it using different classloaders and with the help of the "transloader" [1] library. You can read more about it on my blog [2]. Basically the idea would be to have two versions of the same module that both implement the same Java interface (maybe packaged in a third module). The "main application" should be able to decide at runtime which version of the "implementation module" to use. From the APIs available on the website, I think I understand that it is possible to go find these two modules, and obtain a classloader for them. But what if I call methods on objects instantiated on this classloader from within the "main application"? This is a problem we currently solved with the transloader library (which serializes and deserializes under the hood). Will this situation be different with Jigsaw? Thanks in advance, Jan [1] http://code.google.com/p/transloader/ [2] http://janvanbesien.blogspot.com/2008/12/runtime-dispatch-between-different.html From Karen.Kinnear at Sun.COM Fri Feb 6 11:33:45 2009 From: Karen.Kinnear at Sun.COM (Karen Kinnear) Date: Fri, 06 Feb 2009 14:33:45 -0500 Subject: JLS changes for module impact on inheritance and overriding? Message-ID: <2B534DFA-6A61-4BCC-8E7E-2DD2464E3B30@Sun.COM> Alex, With this JSR 294 proposal, would you expect to also change the JLS in the following ways? See the text added in blue below relative to JLS 3rd edition. I am currently assuming these changes in the prototype I am making with the hotspot vm. thanks, Karen 8.4.8 Inheritance, Overriding, and Hiding A class C inherits from its direct superclass and direct superinterfaces all non-private methods (whether abstract or not) of the superclass and superinterfaces that are public, protected or declared module and in the same module as C, or declared with default access in the same package as C and are neither overridden (?8.4.8.1) nor hidden (?8.4.8.2) by a declaration in the class. 8.4.8.1 Overriding (by Instance Methods) An instance method m1 declared in a class C overrides another instance method, m2, declared in class A iff all of the following are true: C is a subclass of A. The signature of m1 is a subsignature (?8.4.2) of the signature of m2. Either m2 is public, protected or declared module and in the same module as C, or declared with default access in the same package as C, or m1 overrides a method m3, m3 distinct from m1, m3 distinct from m2, such that m3 overrides m2. Moreover, if m1 is not abstract, then m1 is said to implement any and all declarations of abstract methods that it overrides. From Jonathan.Gibbons at Sun.COM Fri Feb 6 11:51:34 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 06 Feb 2009 11:51:34 -0800 Subject: JLS changes for module impact on inheritance and overriding? In-Reply-To: <2B534DFA-6A61-4BCC-8E7E-2DD2464E3B30@Sun.COM> References: <2B534DFA-6A61-4BCC-8E7E-2DD2464E3B30@Sun.COM> Message-ID: <498C94C6.4090500@sun.com> Karen, No blue text here. -- Jon Karen Kinnear wrote: > > Alex, > > With this JSR 294 proposal, would you expect to also change the JLS > in the following ways? See the text > added in blue below relative to JLS 3rd edition. > > I am currently assuming these changes in the prototype I am making > with the hotspot vm. > > thanks, > Karen > > 8.4.8 Inheritance, Overriding, and Hiding > > A class C inherits from its direct superclass and direct > superinterfaces all non-private methods (whether abstract or not) of > the superclass and superinterfaces that are public, protected or > declared module and in the same module as C, or declared with default > access in the same package as C and are neither overridden (?8.4.8.1) > nor hidden (?8.4.8.2) by a declaration in the class. > > 8.4.8.1 Overriding (by Instance Methods) > > An instance method m1 declared in a class C overrides another instance > method, m2, declared in class A iff all of the following are true: > > C is a subclass of A. > The signature of m1 is a subsignature (?8.4.2) of the signature of m2. > Either > m2 is public, protected or declared module and in the same module as > C, or declared with default access in the same package as C, or > m1 overrides a method m3, m3 distinct from m1, m3 distinct from m2, > such that m3 overrides m2. > Moreover, if m1 is not abstract, then m1 is said to implement any and > all declarations of abstract methods that it overrides. From Karen.Kinnear at Sun.COM Fri Feb 6 12:01:49 2009 From: Karen.Kinnear at Sun.COM (Karen Kinnear) Date: Fri, 06 Feb 2009 15:01:49 -0500 Subject: JLS changes for module impact on inheritance and overriding? In-Reply-To: <498C94C6.4090500@sun.com> References: <2B534DFA-6A61-4BCC-8E7E-2DD2464E3B30@Sun.COM> <498C94C6.4090500@sun.com> Message-ID: <25525430-DA54-47AA-88A2-82A4A0D551E5@Sun.COM> Thanks Jon - skip the color coding, let's see if bolding works better. thanks, Karen On Feb 6, 2009, at 2:51 PM, Jonathan Gibbons wrote: > Karen, > > No blue text here. > > -- Jon > > > Karen Kinnear wrote: >> >> Alex, >> >> With this JSR 294 proposal, would you expect to also change the >> JLS in the following ways? See the text >> added in blue below relative to JLS 3rd edition. >> >> I am currently assuming these changes in the prototype I am making >> with the hotspot vm. >> >> thanks, >> Karen >> >> 8.4.8 Inheritance, Overriding, and Hiding >> >> A class C inherits from its direct superclass and direct >> superinterfaces all non-private methods (whether abstract or not) >> of the superclass and superinterfaces that are public, protected or >> declared module and in the same module as C, or declared with >> default access in the same package as C and are neither overridden >> (?8.4.8.1) nor hidden (?8.4.8.2) by a declaration in the class. >> >> 8.4.8.1 Overriding (by Instance Methods) >> >> An instance method m1 declared in a class C overrides another >> instance method, m2, declared in class A iff all of the following >> are true: >> >> C is a subclass of A. >> The signature of m1 is a subsignature (?8.4.2) of the signature of >> m2. >> Either >> m2 is public, protected or declared module and in the same module >> as C, or declared with default access in the same package as C, or >> m1 overrides a method m3, m3 distinct from m1, m3 distinct from m2, >> such that m3 overrides m2. >> Moreover, if m1 is not abstract, then m1 is said to implement any >> and all declarations of abstract methods that it overrides. > From Alex.Buckley at Sun.COM Fri Feb 6 20:14:20 2009 From: Alex.Buckley at Sun.COM (Alex Buckley) Date: Fri, 06 Feb 2009 20:14:20 -0800 Subject: JLS changes for module impact on inheritance and overriding? In-Reply-To: <2B534DFA-6A61-4BCC-8E7E-2DD2464E3B30@Sun.COM> References: <2B534DFA-6A61-4BCC-8E7E-2DD2464E3B30@Sun.COM> Message-ID: <498D0A9C.5040206@sun.com> Yes. Those exact changes are in Framemaker files I prepared for EDR2 of 277. Changes also in chapters 6, 13, 15. Ultimately they are not controversial but I don't want to publish them because complete public specs are not what will determine whether 294 is accepted. For example, Jesse Glick has sent me an enormous mail which drops modules in favor of friends; thankfully he has been unable to post it to -observer for some reason. It's one thing to let Richard Hall have free rein on the EG, but Jesse's blundering must be stopped. Alex Karen Kinnear wrote: > Alex, > > With this JSR 294 proposal, would you expect to also change the JLS in > the following ways? See the text > added in blue below relative to JLS 3rd edition. > > I am currently assuming these changes in the prototype I am making with > the hotspot vm. > > thanks, > Karen > > 8.4.8 Inheritance, Overriding, and Hiding > > A class C inherits from its direct superclass and direct superinterfaces > all non-private methods (whether abstract or not) of the superclass and > superinterfaces that are public, protected or declared module and in the > same module as C, or declared with default access in the same package as > C and are neither overridden (?8.4.8.1) nor hidden (?8.4.8.2) by a > declaration in the class. > > 8.4.8.1 Overriding (by Instance Methods) > > An instance method m1 declared in a class C overrides another instance > method, m2, declared in class A iff all of the following are true: > > C is a subclass of A. > The signature of m1 is a subsignature (?8.4.2) of the signature of m2. > Either > m2 is public, protected or declared module and in the same module as C, > or declared with default access in the same package as C, or > m1 overrides a method m3, m3 distinct from m1, m3 distinct from m2, such > that m3 overrides m2. > Moreover, if m1 is not abstract, then m1 is said to implement any and > all declarations of abstract methods that it overrides. From Alex.Buckley at Sun.COM Fri Feb 6 21:42:32 2009 From: Alex.Buckley at Sun.COM (Alex Buckley) Date: Fri, 06 Feb 2009 21:42:32 -0800 Subject: JLS changes for module impact on inheritance and overriding? In-Reply-To: <498D0A9C.5040206@sun.com> References: <2B534DFA-6A61-4BCC-8E7E-2DD2464E3B30@Sun.COM> <498D0A9C.5040206@sun.com> Message-ID: <498D1F48.8000506@sun.com> My previous post to jigsaw-dev was not meant for public consumption. First, changes to the Java Language Spec for module-private accessibility belong on the 294 lists, not here. Second, the tone was quite out of order and I publicly apologize to Jesse for referring to his internal comments in the way that I did. Alex From mcculls at gmail.com Fri Feb 6 22:43:16 2009 From: mcculls at gmail.com (Stuart McCulloch) Date: Sat, 7 Feb 2009 14:43:16 +0800 Subject: JLS changes for module impact on inheritance and overriding? In-Reply-To: <498D1F48.8000506@sun.com> References: <2B534DFA-6A61-4BCC-8E7E-2DD2464E3B30@Sun.COM> <498D0A9C.5040206@sun.com> <498D1F48.8000506@sun.com> Message-ID: <81f0d9c0902062243r2ff5a311s7de27ba19d73517e@mail.gmail.com> 2009/2/7 Alex Buckley > My previous post to jigsaw-dev was not meant for public consumption. First, > changes to the Java Language Spec for module-private accessibility belong on > the 294 lists, not here. Second, the tone was quite out of order and I > publicly apologize to Jesse for referring to his internal comments in the > way that I did. > yes, that was rather unfortunate - I've often wanted a short-term "unsend" button for email! but I would also like to think the expert group encourages free discussion where possible... Alex > -- Cheers, Stuart From Jonathan.Gibbons at Sun.COM Tue Feb 10 17:44:06 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 10 Feb 2009 17:44:06 -0800 Subject: degenerate module-info Message-ID: <49922D66.9050609@sun.com> Alex, In the context of the proposed specs [1], is it permissable for a degenerate module to not have its own module compilation unit? -- Jon [1] http://openjdk.java.net/projects/jigsaw/doc/language.html From Jonathan.Gibbons at Sun.COM Tue Feb 10 18:06:10 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 10 Feb 2009 18:06:10 -0800 Subject: compiling with multiple versions of a class Message-ID: <49923292.3030909@sun.com> Jigsaw folk, Are there any credible scenarios in which we would expect a single compilation to be able to accomodate multiple versions of a class, either in a .class or a .java file? If so, are these scenarios important, or can we accept as a restriction that any one compilation can only handle one version of a class, and that it would be a compile-time error for different files in a compilation to depend on different versions of a class? -- Jon From Jonathan.Gibbons at Sun.COM Wed Feb 11 08:41:46 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Wed, 11 Feb 2009 08:41:46 -0800 Subject: Jigsaw/JDK requirements Message-ID: Jigsaw folk, (Thinking aloud a bit) Are there any de-facto requirements coming from the desire to modularize JDK? Specifically, is there are constraint to keep the shape of the source tree largely unchanged, or would we entertain the notion of reorganizing the source tree by module? Would the SCM implications of that be way too onerous? I ask, because it again comes up in the context of the shape of the classes tree, and the desire to have the classes directory structure be isomorphic to the source directory structure -- and Alex recently re-suggested encoding the module name (but not the version, this time) in the classes/ hierarchy. -- Jon From Jonathan.Gibbons at Sun.COM Wed Feb 11 09:21:34 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Wed, 11 Feb 2009 09:21:34 -0800 Subject: Repository changesets Message-ID: Mark, What are the basic guidelines for pushing jigsaw repository changesets? I presume jcheck is not enabled. Is it enough to check whitespace and use a "reasonable" comment in the summary? What about sync-ing with the main jdk7 forest? If so, who and how often? Do you want Hudson to build the jigsaw repositories for verification? -- Jon From mr at sun.com Wed Feb 11 13:22:40 2009 From: mr at sun.com (Mark Reinhold) Date: Wed, 11 Feb 2009 13:22:40 -0800 Subject: Repository changesets In-Reply-To: jonathan.gibbons@sun.com; Wed, 11 Feb 2009 09:21:34 PST; Message-ID: <20090211212240.2A08A28CF3F@eggemoggin.niobe.net> > Date: Wed, 11 Feb 2009 09:21:34 -0800 > From: jonathan.gibbons at sun.com > What are the basic guidelines for pushing jigsaw repository > changesets? I presume jcheck is not enabled. Correct. > Is it enough to check > whitespace and use a "reasonable" comment in the summary? Yep. We can even live without code reviews, for now. Just so everyone knows: The plan here is to work on the early stages of Jigsaw in a riskier, more agile style so that we can make rapid progress. When we're ready to integrate into the mainline code base then we'll do so via one giant patch which creates just one changeset in each affected repository. Long term, our early development history will only exist in the Jigsaw Project's archives. > What about sync-ing with the main jdk7 forest? If so, who and how > often? Good question. I've been hacking on a clone of b46, and I should be ready to publish that code soon, so let's consider b46 our starting point. We should try to stay reasonably up-to-date. Syncing every other build is likely good enough for now. > Do you want Hudson to build the jigsaw repositories for > verification? That'd be good. Do you have, or know of, a Hudson instance we could use for this? - Mark From Jonathan.Gibbons at Sun.COM Wed Feb 11 13:37:37 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Wed, 11 Feb 2009 13:37:37 -0800 Subject: Repository changesets In-Reply-To: <20090211212240.2A08A28CF3F@eggemoggin.niobe.net> References: <20090211212240.2A08A28CF3F@eggemoggin.niobe.net> Message-ID: <49934521.9070802@sun.com> Mark Reinhold wrote: > >> Do you want Hudson to build the jigsaw repositories for >> verification? >> > > That'd be good. Do you have, or know of, a Hudson instance we could use > for this? > I have one (within the Sun firewall, on javac.sfbay) that we could use. It is set up for Solaris (only) builds -- i.e. I don't (yet) use the Hudson features for multi-machine slave builds. If we wanted that, I would start looking at JPRT instead. -- Jon From Jonathan.Gibbons at Sun.COM Thu Feb 12 16:28:55 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Thu, 12 Feb 2009 16:28:55 -0800 Subject: javac issues with proposed API Message-ID: <4994BEC7.50806@sun.com> Mark, I am uncovering issues with the proposed new API as it pertains to javac. Some of this we sensed before, but we can start to be more specific. 1. ModuleInfo ModuleInfo extends java.lang.reflect.AnnotatedElement. While this is acceptable for runtime access, it is not acceptable for javac. Rightly or wrongly, annotations potentially involve Class items, and javac does not want to load any classes into any class loader in order to access a ModuleInfo which might have such an annotation. This is why the JSR 269 API mirrors rather than reuses the java.lang.reflect hierarchy. 2. ModuleLibrary.findModule This is commented as "for javac", but javac is going to need something more. The method seems to assume that the module library has complete knowledge of the available modules, which may not be true if some module-info files are being provided on the command line. This is where we need the beginning of the "module info graph" we have talked about on and off. Either we need to be able to query the module library to get candidate module-info files for any given module name, so that we can build the module info graph externally to the library, or we will need to pass in to the module library information about modules being compiled so that the library can take it into account as part of the findModule call. In effect, this latter case corresponds to reifying the module info graph inside the module library implementation. In either case, javac will have to communicate with the module library using some sort of module info, which ties this issue to the earlier issue about ModuleInfo. As a general observation, you could draw an analogy with the need for the JigsawModuleClassLoader.defineClass(Module , ...) method. That is the means by which the runtime becomes aware of new modules in the system, such that ModuleLibrary.findModule can give the correct response. There is currently no such equivalent call for the compiler to use. I'll see what it takes to come up with a module info graph API that addresses these concerns. -- Jon From mr at sun.com Fri Feb 20 14:35:54 2009 From: mr at sun.com (Mark Reinhold) Date: Fri, 20 Feb 2009 14:35:54 -0800 Subject: Jigsaw/JDK requirements In-Reply-To: jonathan.gibbons@sun.com; Wed, 11 Feb 2009 08:41:46 PST; Message-ID: <20090220223554.2FA9F291846@eggemoggin.niobe.net> > Date: Wed, 11 Feb 2009 08:41:46 -0800 > From: jonathan.gibbons at sun.com > Are there any de-facto requirements coming from the desire to > modularize JDK? Specifically, is there are constraint to keep the > shape of the source tree largely unchanged, or would we entertain the > notion of reorganizing the source tree by module? I don't think we should consider ourselves constrained to preserve the current shape of the source tree. In fact I think it's desirable and appropriate to revise it significantly to reflect the coming, gradual modularization of the product bits. That way we can gain the benefits of modularity not only when working on source code or delivering bits, but also when working on the source tree itself. I've been thinking that where today we have jdk/src/{share,solaris,windows}/classes/... jdk/src/{share,solaris,windows}/native/... we will shortly have sibling subtrees jdk/src/{share,solaris,windows}/modules/... where each module directory can have classes, native, and whatever other subdirectories it requires. Over time code will move from the first set of subtrees to the second. We can consider the modularization effort complete when it's safe to rm -rf the first set of subtrees. > Would the SCM > implications of that be way too onerous? If they are, then we need a new scm. Mercurial is, fortunately, quite capable of handling mass renames. > I ask, because it again comes up in the context of the shape of the > classes tree, and the desire to have the classes directory structure be > isomorphic to the source directory structure -- and Alex recently > re-suggested encoding the module name (but not the version, this time) > in the classes/ hierarchy. This was the proposal to put module classes into classes/module-classes, right? That wouldn't be exactly isomorphic to what I outlined above, but I'm not sure that it matters a great deal. - Mark From mr at sun.com Fri Feb 20 14:43:39 2009 From: mr at sun.com (Mark Reinhold) Date: Fri, 20 Feb 2009 14:43:39 -0800 Subject: compiling with multiple versions of a class In-Reply-To: jonathan.gibbons@sun.com; Tue, 10 Feb 2009 18:06:10 PST; <49923292.3030909@sun.com> Message-ID: <20090220224339.34C62291846@eggemoggin.niobe.net> > Date: Tue, 10 Feb 2009 18:06:10 -0800 > From: jonathan.gibbons at sun.com > Are there any credible scenarios in which we would expect a single > compilation to be able to accomodate multiple versions of a class, > either in a .class or a .java file? If so, are these scenarios > important, or can we accept as a restriction that any one compilation > can only handle one version of a class, and that it would be a > compile-time error for different files in a compilation to depend on > different versions of a class? I can certainly live with that restriction, especially if it makes the compiler (writer's) job significantly easier. - Mark From Jonathan.Gibbons at Sun.COM Fri Feb 20 15:00:18 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 20 Feb 2009 15:00:18 -0800 Subject: Jigsaw/JDK requirements In-Reply-To: <20090220223554.2FA9F291846@eggemoggin.niobe.net> References: <20090220223554.2FA9F291846@eggemoggin.niobe.net> Message-ID: <499F3602.1080901@sun.com> While Mercurial can handle mass renames, it does it in a clumsy way (doesn't it?) as a combination of a delete and a new file. Although it doesn't cost you in the working directory, it will cost you in the .hg directory, won't it? -- Jon Mark Reinhold wrote: >> Date: Wed, 11 Feb 2009 08:41:46 -0800 >> From: jonathan.gibbons at sun.com >> > > >> Are there any de-facto requirements coming from the desire to >> modularize JDK? Specifically, is there are constraint to keep the >> shape of the source tree largely unchanged, or would we entertain the >> notion of reorganizing the source tree by module? >> > > I don't think we should consider ourselves constrained to preserve the > current shape of the source tree. In fact I think it's desirable and > appropriate to revise it significantly to reflect the coming, gradual > modularization of the product bits. That way we can gain the benefits > of modularity not only when working on source code or delivering bits, > but also when working on the source tree itself. > > I've been thinking that where today we have > > jdk/src/{share,solaris,windows}/classes/... > jdk/src/{share,solaris,windows}/native/... > > we will shortly have sibling subtrees > > jdk/src/{share,solaris,windows}/modules/... > > where each module directory can have classes, native, and whatever > other subdirectories it requires. > > Over time code will move from the first set of subtrees to the second. > We can consider the modularization effort complete when it's safe to > rm -rf the first set of subtrees. > > >> Would the SCM >> implications of that be way too onerous? >> > > If they are, then we need a new scm. Mercurial is, fortunately, quite > capable of handling mass renames. > > >> I ask, because it again comes up in the context of the shape of the >> classes tree, and the desire to have the classes directory structure be >> isomorphic to the source directory structure -- and Alex recently >> re-suggested encoding the module name (but not the version, this time) >> in the classes/ hierarchy. >> > > This was the proposal to put module classes into classes/module-classes, > right? That wouldn't be exactly isomorphic to what I outlined above, but > I'm not sure that it matters a great deal. > > - Mark > From mr at sun.com Fri Feb 20 15:03:07 2009 From: mr at sun.com (Mark Reinhold) Date: Fri, 20 Feb 2009 15:03:07 -0800 Subject: javac issues with proposed API In-Reply-To: jonathan.gibbons@sun.com; Thu, 12 Feb 2009 16:28:55 PST; <4994BEC7.50806@sun.com> Message-ID: <20090220230307.F21C4291846@eggemoggin.niobe.net> > Date: Thu, 12 Feb 2009 16:28:55 -0800 > From: jonathan.gibbons at sun.com > I am uncovering issues with the proposed new API as it pertains to javac. > Some of this we sensed before, but we can start to be more specific. > > 1. ModuleInfo > > ModuleInfo extends java.lang.reflect.AnnotatedElement. While this is > acceptable for runtime access, it is not acceptable for javac. Rightly > or wrongly, annotations potentially involve Class items, and javac > does not want to load any classes into any class loader in order to access > a ModuleInfo which might have such an annotation. This is why the > JSR 269 API mirrors rather than reuses the java.lang.reflect hierarchy. Good point. I don't see a fundamental reason why ModuleInfo needs to implement AnnotatedElement; java.lang.reflect.Module can do that on its own. I'll change this in my prototype. ModuleInfo, by the way, is now an interface; we'll see if that sticks. > 2. ModuleLibrary.findModule > > This is commented as "for javac", but javac is going to need something > more. The method seems to assume that the module library has complete > knowledge of the available modules, which may not be true if some > module-info files are being provided on the command line. This is where > we need the beginning of the "module info graph" we have talked about > on and off. > > Either we need to be able to query the module library to get candidate > module-info files for any given module name, so that we can build the > module info graph externally to the library, or we will need to pass in to > the module library information about modules being compiled so that the > library can take it into account as part of the findModule call. In effect, > this latter case corresponds to reifying the module info graph inside the > module library implementation. I'd prefer to keep the ModuleLibrary abstraction simple, leaving graph construction and consideration of modules named on a tool's command line to higher levels. > In either case, javac will have to communicate with the module library > using some sort of module info, which ties this issue to the earlier issue > about ModuleInfo. Do you really mean ModuleInfos, or are ModuleIds sufficient? If what you want is public ModuleInfo findModuleInfo(ModuleQuery mq, AgePolicy ap, FormPolicy fp, ModuleInfoFilter midf); then that can be arranged. Such a method could, alternatively, return a Set if you'd prefer that. > As a general observation, you could draw an analogy with the need for > the JigsawModuleClassLoader.defineClass(Module , ...) method. That is > the means by which the runtime becomes aware of new modules in the > system, such that ModuleLibrary.findModule can give the correct response. > There is currently no such equivalent call for the compiler to use. Good analogy, but I still think that method belongs on a higher-level ModuleInfoGraph (or some such) abstraction. - Mark From Jonathan.Gibbons at Sun.COM Fri Feb 20 15:11:43 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 20 Feb 2009 15:11:43 -0800 Subject: javac issues with proposed API In-Reply-To: <20090220230307.F21C4291846@eggemoggin.niobe.net> References: <20090220230307.F21C4291846@eggemoggin.niobe.net> Message-ID: <499F38AF.3060000@sun.com> I agree with keeping the ModuleLibrary abstraction simple, as an API onto the bits on disk, out of which we can build such higher abstractions as necessary. In what I've been considering so far, I think you need the general ability to get a set of ModuleInfo for any given module name. This could either be done by getting a set of ModuleIds and then being able to map any ModuleId to its ModuleInfo, or by getting the set of ModuleInfo directly. Being able to filter the set may be an optional but useful performance tweak. -- Jon Mark Reinhold wrote: >> Date: Thu, 12 Feb 2009 16:28:55 -0800 >> From: jonathan.gibbons at sun.com >> > > >> I am uncovering issues with the proposed new API as it pertains to javac. >> Some of this we sensed before, but we can start to be more specific. >> >> 1. ModuleInfo >> >> ModuleInfo extends java.lang.reflect.AnnotatedElement. While this is >> acceptable for runtime access, it is not acceptable for javac. Rightly >> or wrongly, annotations potentially involve Class items, and javac >> does not want to load any classes into any class loader in order to access >> a ModuleInfo which might have such an annotation. This is why the >> JSR 269 API mirrors rather than reuses the java.lang.reflect hierarchy. >> > > Good point. I don't see a fundamental reason why ModuleInfo needs to > implement AnnotatedElement; java.lang.reflect.Module can do that on its > own. I'll change this in my prototype. > > ModuleInfo, by the way, is now an interface; we'll see if that sticks. > > >> 2. ModuleLibrary.findModule >> >> This is commented as "for javac", but javac is going to need something >> more. The method seems to assume that the module library has complete >> knowledge of the available modules, which may not be true if some >> module-info files are being provided on the command line. This is where >> we need the beginning of the "module info graph" we have talked about >> on and off. >> >> Either we need to be able to query the module library to get candidate >> module-info files for any given module name, so that we can build the >> module info graph externally to the library, or we will need to pass in to >> the module library information about modules being compiled so that the >> library can take it into account as part of the findModule call. In effect, >> this latter case corresponds to reifying the module info graph inside the >> module library implementation. >> > > I'd prefer to keep the ModuleLibrary abstraction simple, leaving graph > construction and consideration of modules named on a tool's command line > to higher levels. > > >> In either case, javac will have to communicate with the module library >> using some sort of module info, which ties this issue to the earlier issue >> about ModuleInfo. >> > > Do you really mean ModuleInfos, or are ModuleIds sufficient? If what you > want is > > public ModuleInfo > findModuleInfo(ModuleQuery mq, AgePolicy ap, FormPolicy fp, > ModuleInfoFilter midf); > > then that can be arranged. Such a method could, alternatively, return a > Set if you'd prefer that. > > >> As a general observation, you could draw an analogy with the need for >> the JigsawModuleClassLoader.defineClass(Module , ...) method. That is >> the means by which the runtime becomes aware of new modules in the >> system, such that ModuleLibrary.findModule can give the correct response. >> There is currently no such equivalent call for the compiler to use. >> > > Good analogy, but I still think that method belongs on a higher-level > ModuleInfoGraph (or some such) abstraction. > > - Mark > From mr at sun.com Fri Feb 20 15:14:24 2009 From: mr at sun.com (Mark Reinhold) Date: Fri, 20 Feb 2009 15:14:24 -0800 Subject: Jigsaw/JDK requirements In-Reply-To: jonathan.gibbons@sun.com; Fri, 20 Feb 2009 15:00:18 PST; <499F3602.1080901@sun.com> Message-ID: <20090220231424.3C870291846@eggemoggin.niobe.net> > Date: Fri, 20 Feb 2009 15:00:18 -0800 > From: jonathan.gibbons at sun.com > While Mercurial can handle mass renames, it does it in a clumsy way > (doesn't it?) as a combination of a delete and a new file. Although > it doesn't cost you in the working directory, it will cost you in the > .hg directory, won't it? No, not really. The deltas for the original file remain where they were in .hg/store; the new file in the store will only contain newer deltas. The -f option to the hg log command follows across renames so that you can always see the complete history of a file. - Mark From Jonathan.Gibbons at Sun.COM Fri Feb 20 15:25:47 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 20 Feb 2009 15:25:47 -0800 Subject: Jigsaw/JDK requirements In-Reply-To: <20090220231424.3C870291846@eggemoggin.niobe.net> References: <20090220231424.3C870291846@eggemoggin.niobe.net> Message-ID: <499F3BFB.4050900@sun.com> So you do end up with "double inodes" when you rename a file ... I agree the user illusion is good, but I still say it is heavyweight under the covers. For occasional file renames, I don't think it's a big deal; it is arguably more of a big deal if we were to rename most of the files in the JDK repository. -- Jon Mark Reinhold wrote: >> Date: Fri, 20 Feb 2009 15:00:18 -0800 >> From: jonathan.gibbons at sun.com >> > > >> While Mercurial can handle mass renames, it does it in a clumsy way >> (doesn't it?) as a combination of a delete and a new file. Although >> it doesn't cost you in the working directory, it will cost you in the >> .hg directory, won't it? >> > > No, not really. The deltas for the original file remain where they > were in .hg/store; the new file in the store will only contain newer > deltas. The -f option to the hg log command follows across renames > so that you can always see the complete history of a file. > > - Mark > From Alex.Buckley at Sun.COM Fri Feb 20 16:00:04 2009 From: Alex.Buckley at Sun.COM (Alex Buckley) Date: Fri, 20 Feb 2009 16:00:04 -0800 Subject: degenerate module-info In-Reply-To: <49922D66.9050609@sun.com> References: <49922D66.9050609@sun.com> Message-ID: <499F4404.4090104@sun.com> Jonathan Gibbons wrote: > In the context of the proposed specs [1], is it permissable > for a degenerate module to not have its own module > compilation unit? Yes. Source files (either individually, or via their package compilation unit) can claim "module M;" without any module compilation unit existing. Even if a module compilation unit for module M does exist, it need not declare a version or dependencies, in which case its utility is limited to annotations. Alex From jonathan.gibbons at sun.com Mon Feb 23 16:48:03 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Tue, 24 Feb 2009 00:48:03 +0000 Subject: hg: jigsaw/jigsaw/langtools: 4 new changesets Message-ID: <20090224004809.3FB7BDF05@hg.openjdk.java.net> Changeset: fedc96614330 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/fedc96614330 Added tag jdk7-b47 for changeset 2b8f6bab2392 ! .hgtags Changeset: c53007f34195 Author: tbell Date: 2009-02-17 09:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/c53007f34195 Merge Changeset: d17d927ad9bd Author: xdono Date: 2009-02-19 14:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/d17d927ad9bd Added tag jdk7-b48 for changeset c53007f34195 ! .hgtags Changeset: 6f171bbc2939 Author: jjg Date: 2009-02-23 16:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/6f171bbc2939 Merge From jonathan.gibbons at sun.com Mon Feb 23 17:18:15 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Tue, 24 Feb 2009 01:18:15 +0000 Subject: hg: jigsaw/jigsaw/langtools: Initial checkpoint for javac, javap Message-ID: <20090224011816.94239DF0A@hg.openjdk.java.net> Changeset: cb07b0ccd940 Author: jjg Date: 2009-02-23 17:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/cb07b0ccd940 Initial checkpoint for javac, javap ! make/build.xml + src/share/classes/com/sun/source/tree/ModuleClassTree.java + src/share/classes/com/sun/source/tree/ModuleIdTree.java + src/share/classes/com/sun/source/tree/ModulePermitsTree.java + src/share/classes/com/sun/source/tree/ModuleRequiresTree.java + src/share/classes/com/sun/source/tree/ModuleTree.java + src/share/classes/com/sun/source/tree/PackageTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java + src/share/classes/com/sun/tools/classfile/ModuleClass_attribute.java - src/share/classes/com/sun/tools/classfile/ModuleExportTable_attribute.java - src/share/classes/com/sun/tools/classfile/ModuleMemberTable_attribute.java + src/share/classes/com/sun/tools/classfile/ModulePermits_attribute.java + src/share/classes/com/sun/tools/classfile/ModuleProvides_attribute.java + src/share/classes/com/sun/tools/classfile/ModuleRequires_attribute.java ! src/share/classes/com/sun/tools/classfile/Module_attribute.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeTags.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Keywords.java ! src/share/classes/com/sun/tools/javac/parser/Lexer.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/Token.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/Options.java ! src/share/classes/javax/lang/model/element/Modifier.java ! src/share/classes/javax/lang/model/type/TypeKind.java ! test/tools/javac/T6232928.java ! test/tools/javac/T6341023.java + test/tools/javac/modules/ModuleAccessTest01.java + test/tools/javac/modules/ModuleAttributeTest01.java + test/tools/javac/modules/ModuleModifierTest01.java + test/tools/javac/modules/ModulePermitsAttributeTest01.java + test/tools/javac/modules/ModuleProvidesAttributeTest01.java + test/tools/javac/modules/ModuleRequiresAttributeTest01.java From mr at sun.com Mon Feb 23 20:38:31 2009 From: mr at sun.com (mr at sun.com) Date: Tue, 24 Feb 2009 04:38:31 +0000 Subject: hg: jigsaw/jigsaw: 2 new changesets Message-ID: <20090224043831.3887DDFE5@hg.openjdk.java.net> Changeset: 4ae9f4bfdb98 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/4ae9f4bfdb98 Added tag jdk7-b47 for changeset d7744e86dedc ! .hgtags Changeset: aee93a8992d2 Author: xdono Date: 2009-02-19 14:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/aee93a8992d2 Added tag jdk7-b48 for changeset 4ae9f4bfdb98 ! .hgtags From mr at sun.com Mon Feb 23 20:39:51 2009 From: mr at sun.com (mr at sun.com) Date: Tue, 24 Feb 2009 04:39:51 +0000 Subject: hg: jigsaw/jigsaw/corba: 2 new changesets Message-ID: <20090224043953.D68D2DFF3@hg.openjdk.java.net> Changeset: 0be222241fd4 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/0be222241fd4 Added tag jdk7-b47 for changeset 167ad0164301 ! .hgtags Changeset: d70978bc64bc Author: xdono Date: 2009-02-19 14:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/d70978bc64bc Added tag jdk7-b48 for changeset 0be222241fd4 ! .hgtags From mr at sun.com Mon Feb 23 20:42:22 2009 From: mr at sun.com (mr at sun.com) Date: Tue, 24 Feb 2009 04:42:22 +0000 Subject: hg: jigsaw/jigsaw/hotspot: 34 new changesets Message-ID: <20090224044330.18EBDDFFA@hg.openjdk.java.net> Changeset: 3cd5c5b027b1 Author: trims Date: 2008-12-23 19:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/3cd5c5b027b1 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM Summary: fork Hotspot 15 - redo verisoning numbers Reviewed-by: jcoomes ! make/hotspot_version Changeset: 6d8fc951eb25 Author: kvn Date: 2008-12-22 15:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/6d8fc951eb25 6778657: Casts in SharedRuntime::f2i, f2l, d2i and d2l rely on undefined C++ behaviour Summary: Replaces SharedRuntime::f2i et al with versions that should work Reviewed-by: never Contributed-by: gbenson at redhat.com ! src/share/vm/runtime/sharedRuntime.cpp + test/compiler/6778657/Test.java Changeset: 9656bebe85a7 Author: kvn Date: 2008-12-22 16:53 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/9656bebe85a7 6778662: fixes 64-bits libraries directory search paths on linux Summary: Fixes 64-bits libraries directory search paths. Reviewed-by: never Contributed-by: langel at redhat.com ! src/os/linux/vm/os_linux.cpp Changeset: 1a767c61ad01 Author: never Date: 2009-01-06 16:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/1a767c61ad01 Merge Changeset: dabd8d202164 Author: coleenp Date: 2008-12-23 06:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/dabd8d202164 4997835: RFE: crash dump will only be created when running w/ -XX:+ShowMessageBoxOnError Summary: Using UseOSErrorReporting will provide both an hs_err file and a crash dump or debug launch and works better. Reviewed-by: xlu, acorn, poonam ! src/share/vm/utilities/vmError.cpp Changeset: db4caa99ef11 Author: xlu Date: 2008-12-24 13:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/db4caa99ef11 6787106: Hotspot 32 bit build fails on platforms having different definitions for intptr_t & int32_t Summary: Avoid casting between int32_t and intptr_t specifically for MasmAssembler::movptr in 32 bit platforms. Reviewed-by: jrose, kvn ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/x86_32.ad ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp Changeset: 2328d1d3f8cf Author: xlu Date: 2008-12-24 19:13 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/2328d1d3f8cf 6781583: Hotspot build fails on linux 64 bit platform with gcc 4.3.2 Summary: Fixed the wrong cast between types since more restrictions are imposed by gcc 4.3.2 Reviewed-by: jcoomes, acorn, phh, never ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/x86/vm/jni_x86.h ! src/os/linux/vm/os_linux.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/libadt/port.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/vmError.hpp Changeset: c81d2ef51ca3 Author: acorn Date: 2009-01-05 13:44 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/c81d2ef51ca3 4670071: loadClassInternal is too restrictive. Summary: VM support for deadlock fix. Library fix in 4735126. See API proposal. Reviewed-by: dholmes, blacklion ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/globals.hpp Changeset: a0401dc51d0b Author: acorn Date: 2009-01-08 16:27 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/a0401dc51d0b 6791656: nsk defclass0 asserts handles.hpp Reviewed-by: phh, xlu ! src/share/vm/classfile/systemDictionary.cpp Changeset: fc7ab6287598 Author: coleenp Date: 2009-01-09 14:39 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/fc7ab6287598 Merge ! src/os/linux/vm/os_linux.cpp ! src/share/vm/oops/constantPoolOop.cpp Changeset: e9be0e04635a Author: jmasa Date: 2009-01-06 07:05 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/e9be0e04635a 6689653: JMapPerm fails with UseConcMarkSweepIncGC and compressed oops off Summary: Added safe_object_iterate() for use by JMapPerm. Reviewed-by: tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/services/heapDumper.cpp Changeset: 0af8b0718fc9 Author: jmasa Date: 2009-01-11 16:58 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/0af8b0718fc9 6692899: CMS: many vm.parallel_class_loading tests fail with assert "missing Printezis mark" Summary: The CMS concurrent precleaning and concurrent marking phases should work around classes that are undergoing redefinition. Reviewed-by: ysr, dcubed ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constMethodKlass.hpp ! src/share/vm/oops/constMethodOop.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolKlass.hpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 65de26b5ea82 Author: jcoomes Date: 2009-01-14 14:12 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/65de26b5ea82 Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 52a431267315 Author: coleenp Date: 2009-01-13 14:41 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/52a431267315 6791168: Fix invalid code in bytecodeInterpreter that can cause gcc ICE Summary: Fix compilation errors from latest gcc in CC_INTERP including offending missing void* cast. Reviewed-by: xlu ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp Changeset: 4db4e58c16bd Author: xlu Date: 2009-01-13 12:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/4db4e58c16bd 6791815: Fix for 6471657 can cause deadlock on non-Solaris platforms when initializing direct buffer support Summary: Place the state transition inside the loop so that the VMThread could proceed for safepoint Reviewed-by: dholmes, never, acorn ! src/share/vm/prims/jni.cpp Changeset: 9250583801d2 Author: xlu Date: 2009-01-13 12:14 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/9250583801d2 Merge Changeset: 2ddbaf7b8e1c Author: xlu Date: 2009-01-13 14:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/2ddbaf7b8e1c Merge Changeset: c9004fe53695 Author: xlu Date: 2009-01-13 17:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/c9004fe53695 6792301: StackAlignmentInBytes not honored for compiled native methods Summary: Fixed the stack misalignment when generate_native_wrapper is called. Reviewed-by: never, kamg, kvn, phh ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp Changeset: f6c0827e5919 Author: coleenp Date: 2009-01-15 12:44 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/f6c0827e5919 Merge Changeset: 818efdefcc99 Author: tonyp Date: 2009-01-16 13:02 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/818efdefcc99 6484956: G1: improve evacuation pause efficiency Summary: A bunch of performance optimizations to decrease GC pause times in G1. Reviewed-by: apetrusenko, jmasa, iveresov ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/includeDB_gc_shared Changeset: 2b1de1db9a9d Author: jcoomes Date: 2009-01-21 13:40 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/2b1de1db9a9d Merge Changeset: 37b3ca071522 Author: coleenp Date: 2009-01-14 20:14 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/37b3ca071522 6793825: Missing include dependancies for GCC without predefined headers Summary: With predefined headers off for gcc, some .inline.hpp files aren't included to make definition visible for inline functions Reviewed-by: jcoomes, xlu ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/includeDB_gc_parNew ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/includeDB_compiler2 ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features Changeset: 8db2b3e46c38 Author: swamyv Date: 2009-01-14 19:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/8db2b3e46c38 6786948: SA on core file fails on solaris-amd64 if vm started with -XX:+StartAttachListener Reviewed-by: jjh, dcubed ! agent/src/os/linux/ps_core.c ! agent/src/os/solaris/proc/saproc.cpp Changeset: fc14734c5aec Author: swamyv Date: 2009-01-15 13:30 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/fc14734c5aec Merge Changeset: 40ee984935b9 Author: phh Date: 2009-01-21 11:14 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/40ee984935b9 6792705: Add JAR file to bootclasspath when using AggressiveOpts Summary: During argument processing, add alt-rt.jar to the bootclasspath between bootclasspath/p and default elements. Reviewed-by: xlu, coleenp ! src/share/vm/runtime/arguments.cpp Changeset: 99c597293e35 Author: coleenp Date: 2009-01-23 10:41 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/99c597293e35 Merge ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: dc3ad84615cf Author: xlu Date: 2009-01-26 12:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/dc3ad84615cf 6795913: A few remaining wrong casts need to be fixed for building hotspot successfully on Mac OS. Summary: Use NULL_WORD in the places where intptr_t is expected due to incompatible types between intptr_t & int32_t Reviewed-by: phh, coleenp, never ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp Changeset: 5cfd8d19e546 Author: ysr Date: 2009-01-26 12:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/5cfd8d19e546 6786503: Overflow list performance can be improved Summary: Avoid overflow list walk in CMS & ParNew when it is unnecessary. Fix a couple of correctness issues, including a C-heap leak, in ParNew at the intersection of promotion failure, work queue overflow and object array chunking. Add stress testing option and related assertion checking. Reviewed-by: jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/includeDB_gc_parNew ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/runtime/globals.hpp Changeset: 4e400c36026f Author: iveresov Date: 2009-01-27 18:13 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/4e400c36026f 6783381: NUMA allocator: don't pretouch eden space with UseNUMA Summary: Moved pretouching to MutableSpace. Also MutableSpace now turns on page interleaving for the region it covers. Reviewed-by: jmasa, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.hpp Changeset: 5b39c489c39d Author: ysr Date: 2009-01-29 21:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/5b39c489c39d Merge ! src/share/vm/gc_implementation/includeDB_gc_parNew Changeset: 3f844a28c5f4 Author: trims Date: 2009-01-30 15:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/3f844a28c5f4 Merge Changeset: fcb923bad68e Author: trims Date: 2009-02-10 20:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/fcb923bad68e Merge Changeset: bcb33806d186 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/bcb33806d186 Added tag jdk7-b47 for changeset fcb923bad68e ! .hgtags Changeset: d61c7c22b25c Author: xdono Date: 2009-02-19 14:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/d61c7c22b25c Added tag jdk7-b48 for changeset bcb33806d186 ! .hgtags From mr at sun.com Mon Feb 23 20:47:16 2009 From: mr at sun.com (mr at sun.com) Date: Tue, 24 Feb 2009 04:47:16 +0000 Subject: hg: jigsaw/jigsaw/jaxp: 2 new changesets Message-ID: <20090224044720.3C7ECE005@hg.openjdk.java.net> Changeset: 39de90eb4822 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/39de90eb4822 Added tag jdk7-b47 for changeset d711ad1954b2 ! .hgtags Changeset: 5c1f24531903 Author: xdono Date: 2009-02-19 14:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/5c1f24531903 Added tag jdk7-b48 for changeset 39de90eb4822 ! .hgtags From mr at sun.com Mon Feb 23 20:48:43 2009 From: mr at sun.com (mr at sun.com) Date: Tue, 24 Feb 2009 04:48:43 +0000 Subject: hg: jigsaw/jigsaw/jaxws: 2 new changesets Message-ID: <20090224044846.C42D6E00C@hg.openjdk.java.net> Changeset: 01e5dd31d0c1 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/01e5dd31d0c1 Added tag jdk7-b47 for changeset 223011570edb ! .hgtags Changeset: 18ca864890f3 Author: xdono Date: 2009-02-19 14:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/18ca864890f3 Added tag jdk7-b48 for changeset 01e5dd31d0c1 ! .hgtags