From mark at klomp.org Fri May 1 00:35:57 2009 From: mark at klomp.org (Mark Wielaard) Date: Fri, 01 May 2009 09:35:57 +0200 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <49F9F971.1010404@sun.com> References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <1234731237.3562.6.camel@hermans.wildebeest.org> <17c6771e0902151453t523b15derfc243ffaa201264f@mail.gmail.com> <1234768690.24153.28.camel@localhost.localdomain> <1234772748.3612.3.camel@hermans.wildebeest.org> <1234774554.11228.3.camel@localhost.localdomain> <1234862105.4062.8.camel@fedora.wildebeest.org> <499B727D.6060901@sun.com> <17c6771e0903200428j75e26899x9c15daf57f5ed20e@mail.gmail.com> <49E3ABEA.6020400@sun.com> <1241001697.4267.1.camel@fedora.wildebeest.org> <49F9F971.1010404@sun.com> Message-ID: <1241163358.4571.17.camel@hermans.wildebeest.org> Hi David, On Thu, 2009-04-30 at 12:18 -0700, David Cox wrote: > "Real soon now" is now, finally. We at Sun have been discussing the > idea of creating a "HotSpot Express" Project in OpenJDK through which > the stabilization of new versions of HotSpot could be managed. We > could create repositories such as > > http://hg.openjdk.java.net/hsx/14/baseline > http://hg.openjdk.java.net/hsx/14/master > > and > > http://hg.openjdk.java.net/hsx/15/baseline > http://hg.openjdk.java.net/hsx/15/master > > in which this work would be done. A "baseline" repo would be used to > collect suitable bug fixes from developers. Occasionally, these > changes would be pushed to "master" to form the basis of a stable > build. This is the model we've used at Sun for many years. If it > seems reasonable to folks, I'll ask one of HotSpot Group members to > submit a formal project proposal for consideration (Although I'm the > manager of Sun's HotSpot garbage collection and compiler teams, I'm > not actually a member of the group!) That sounds good. Thanks. So, if I understand the proposed workflow correctly, general hotspot development on the compiler, garbage collectors and runtime, will go on in the http://hg.openjdk.java.net/jdk7/hotspot-*/hotspot repos, which will be combined and merged into the http://hg.openjdk.java.net/jdk7/hotspot/hotspot/ repo by one of the hotspot gatekeepers. Then when a new "express edition" should be created a new branch under http://hg.openjdk.java.net/hsx/[xy]/baseline is made from that. And when the baseline is declared "stable" the fixes there will be pushed into http://hg.openjdk.java.net/hsx/[xy]/master. One of these hsx/[xy]/master sources will then be selected to be in http://hg.openjdk.java.net/jdk7/jdk7/hotspot/ and http://hg.openjdk.java.net/jdk6/jdk6/hotspot/ Cheers, Mark From David.Cox at Sun.COM Fri May 1 11:58:41 2009 From: David.Cox at Sun.COM (David Cox) Date: Fri, 01 May 2009 11:58:41 -0700 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <1241163358.4571.17.camel@hermans.wildebeest.org> References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <1234731237.3562.6.camel@hermans.wildebeest.org> <17c6771e0902151453t523b15derfc243ffaa201264f@mail.gmail.com> <1234768690.24153.28.camel@localhost.localdomain> <1234772748.3612.3.camel@hermans.wildebeest.org> <1234774554.11228.3.camel@localhost.localdomain> <1234862105.4062.8.camel@fedora.wildebeest.org> <499B727D.6060901@sun.com> <17c6771e0903200428j75e26899x9c15daf57f5ed20e@mail.gmail.com> <49E3ABEA.6020400@sun.com> <1241001697.4267.1.camel@fedora.wildebeest.org> <49F9F971.1010404@sun.com> <1241163358.4571.17.camel@hermans.wildebeest.org> Message-ID: <49FB4661.8070508@sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090501/f4e4d3f5/attachment.html From jeff at cooljeff.co.uk Sun May 3 08:46:04 2009 From: jeff at cooljeff.co.uk (Jeffrey Sinclair) Date: Sun, 03 May 2009 16:46:04 +0100 Subject: invokevirtual on package private override in different classloader In-Reply-To: <49FA2F8E.8080707@sun.com> References: <1239417256.6194.53.camel@Lini> <49E4E45E.2020508@sun.com> <1239744795.6111.32.camel@Lini> <1240072355.6002.2.camel@Lini> <1240074472.6002.5.camel@Lini> <49F0DF27.1010704@sun.com> <49F0F1E3.4080403@sun.com> <4F62E260-841E-41D9-9227-E040F81962CF@Sun.COM> <1240693711.6027.88.camel@Lini> <49F5EC2F.1020705@sun.com> <49F5F3B4.9010202@sun.com> <1240868285.6044.70.camel@Lini> <49FA2F8E.8080707@sun.com> Message-ID: <1241365564.6319.2.camel@Lini> Thanks Alex. This is the missing piece of the puzzle for me, namely the JVMS 3rd edition which has the JVM specific definition of 'override'. I'd like to thank Karen, David and yourself for helping me understand this behaviour. If it is of any interest, I've blogged it here: http://www.cooljeff.co.uk/2009/05/03/the-subtleties-of-overriding-package-private-methods/ Jeff On Thu, 2009-04-30 at 16:09 -0700, Alex Buckley wrote: > Hi Jeff, > > You're right that the JVMS should be independent of the JLS. The Third > Edition of the JVMS drops the chapter on Java Programming Langage > Concepts entirely, but gains a JVM-specific definition of 'overrides': > > An instance method m1 declared in class C overrides another instance > method m2 declared in class A iff all of the following are true: > - C is a subclass of A > - m2 has the same name and descriptor as m1 > - Either: > - m2 is public, protected, or declared with default access in the > same runtime package as C, or > - m1 overrides a method m3, m3 distinct from m1, m3 distinct from > m2, such that m3 overrides m2. > > (The reason why invokevirtual needs to change from 'is accessible' to > 'overrides' is strongly related to the following document from the late > 1990s (!) that explains a change between the JLS 1st and 2nd editions: > http://java.sun.com/docs/books/jls/method-override-rationale.html) > > Before you ask, publication of the Third Edition of the JVMS is delayed > for administrative reasons. > > Your example's behavior is unchanged under the above definition. > CustomSquare::getColour() does not override Square::getColour() and thus > is not selected for invocation. Don't split packages! :-) > > Alex > > Jeffrey Sinclair wrote: > > Hi Karen, > > > > There are no languages that I'm specifically involved in, I would love > > to some day get involved more heavily in either the JVM or the language > > specification. At the moment I'm just your standard Java developer with > > an interest in this. > > > > Apologies for causing trouble, I admit that I'm being very picky here > > and perhaps unnecessarily picky. The issue I have is that before this > > amendment, the resolution could be read without having to understand the > > language at all. > > > > Now the amendment has included the word 'override' which I believe is a > > language feature because it is not defined in the vm specification > > outside of the condensed chapter on the Java Programming Language > > Concepts. > > > > If I were to write an implementation of the JVM, I now need to > > understand the behaviour of override which in itself is tied into a > > specific language specification version. Hence the JVM now has a > > dependency on the language in order to deal with package private > > matching signatures in different runtime packages (and in fact now for > > any method resolution). > > > > For example, what is permitted as an 'override' means something > > different between Java 1.4 and Java 5 due to covariant return types. > > > > Let me know if my point is not clear or is incorrect. > > > > Regards, > > > > Jeff > > > > On Mon, 2009-04-27 at 14:04 -0400, Karen Kinnear wrote: > >> Resending to fix John Rose's email address > >> > >> thanks, > >> Karen > >> > >> Karen Kinnear wrote: > >>> Jeff, > >>> > >>> Are there particular languages with which you are involved? > >>> Or specific concerns you have relative to OSGi? > >>> > >>> I am explicitly copying John Rose, who has been instrumental > >>> in the multi-language vm efforts, and Alex Buckley, the > >>> current owner of the Java Virtual Machine Specification. > >>> They can better respond to the directions of the specifications > >>> in this context. > >>> > >>> For the specific issue you raised, the amendment did not change > >>> the reliance of the JVMS on the Java Language Specification, so > >>> I'll assume your focus is on the larger context of the question, > >>> and this was just an example. > >>> > >>> thanks, > >>> Karen > >>> > >>> p.s. don't worry about the monaco.sfbay link, that was just > >>> an explanation that for backward compatibility we are not > >>> changing the package private interpretation for invokevirtual. > >>> > >>> > >>> Jeffrey Sinclair wrote: > >>> > >>>> Karen, > >>>> > >>>> Thank you for getting back to me with a detailed explanation. > >>>> > >>>> The concern I have is that there is a clear coupling between the JVM > >>>> specification and the language specification in order to prove the > >>>> correctness of my observations. Whilst I understand that the JVM > >>>> specification is there to support the language specification, I was > >>>> always under the impression that a formal proof of correctness for the > >>>> JVM specification could be done in the absence of the language > >>>> specification. > >>>> > >>>> To quote the JVM specification itself (section 1.2): > >>>> > >>>> "The Java virtual machine knows nothing of the Java programming > >>>> language, only of a particular binary format, the class file format. A > >>>> class file contains Java virtual machine instructions (or bytecodes) and > >>>> a symbol table, as well as other ancillary information." > >>>> > >>>> I appreciate that as the language evolves, additions maybe added to the > >>>> JVM specification to deal with advances in the language, however the > >>>> amendments which you quote appear to break a fundamental principle which > >>>> is explicitly stated in the JVM specification itself, namely the > >>>> awareness required by the JVM on the language. > >>>> > >>>> My personal opinion is that this decoupling becomes of real importance > >>>> as the number of languages that use the JVM as their implementation > >>>> grows and specifically the rules governing package private is likely to > >>>> impact technologies such as OSGI. > >>>> > >>>> At the moment I feel that the amendment, whilst it may have strived to > >>>> remove ambiguity, has resulted in a more serious issue and should be > >>>> revoked. Instead the ambiguity should be resolved within the constraints > >>>> of the JVM specification itself. > >>>> > >>>> I could be way off here, please correct any misunderstanding I have. > >>>> > >>>> Unfortunately I could not access 'monaco.sfbay.sun.com' to read up on > >>>> the package private discussions, the lookup fails. > >>>> > >>>> Regards, > >>>> > >>>> Jeff > >>>> > >>>> On Fri, 2009-04-24 at 08:43 -0400, Karen Kinnear wrote: > >>>> > >>>>> Thanks David for catching that. > >>>>> > >>>>> thanks, > >>>>> Karen > >>>>> > >>>>> On Apr 23, 2009, at 6:55 PM, David Holmes - Sun Microsystems wrote: > >>>>> > >>>>> > >>>>>> Hi Karen, > >>>>>> > >>>>>> I was okay with the explanation until this point: > >>>>>> > >>>>>> > >>>>>>> This discussion of access control omits a related restriction on the > >>>>>>> target of a protected field access or method invocation (the target > >>>>>>> must be of class D or a subtype of D). That requirement is checked > >>>>>> > >>>>>> as > >>>>>> > >>>>>>> part of the verification process (?5.4.1); it is not part of link- > >>>>>> > >>>>>> time > >>>>>> > >>>>>>> access control. > >>>>>>> == > >>>>>>> > >>>>>>> The point here is that the virtual machine in the case of > >>>>>> > >>>>>> invokevirtual, > >>>>>> > >>>>>>> does an accessibility check for the compile-time resolved method, > >>>>>>> Square.getColour() in your example, but does NOT perform an > >>>>>>> accessibility check on the link-time resolved method, or > >>>>>>> CustomSquare.getColour() in your example. > >>>>>> > >>>>>> I don't see the relevance of the quoted rule in this case, because > >>>>>> this is not about the target of protected field/method access. > >>>>>> > >>>>>> As far as I can see the reason there is no IllegalAccessError is > >>>>>> because there is no illegal access: > >>>>>> - statically Printer's call to Square.getColor is fine as they are > >>>>>> in the same compile-time package > >>>>>> - at run-time because CustomSquare.getColor does not override > >>>>>> Square.getColor (because they are in different run-time packages), > >>>>>> CustomSquare.getColor is not selected, but rather Square.getColor is > >>>>>> - At runtime Printer and Square are in the same runtime package, so > >>>>>> Printer's invocation of Square.getColor is legal - even on a > >>>>>> CustomSquare instance > >>>>>> > >>>>>> In short there is no IllegalAccessError because > >>>>>> CustomSquare.getColor is not selected to be called. > >>>>>> > >>>>>> Cheers, > >>>>>> David Holmes > >>>>>> > >>>>>> Karen Kinnear said the following on 04/24/09 07:35: > >>>>>> > >>>>>>> Jeff, > >>>>>>> Thank you so much for making this easy for me to reproduce. > >>>>>>> I think you have two questions here: > >>>>>>> 1) why do you get "red" when you use a different class loader > >>>>>>> for CustomSquare and > >>>>>>> 2) why do you not get an IllegalAccessError when calling > >>>>>>> package private CustomSquare.getColour() from a > >>>>>>> different runtime package. > >>>>>>> These are very important questions and use cases related to > >>>>>>> the first caused significant confusion in the past which > >>>>>>> actually led to a specification modification. > >>>>>>> Let me see if I can explain, first why "red", not "blue", > >>>>>>> and second why you don't get an IllegalAccessError. > >>>>>>> First, I too found that Printer and Square are loaded by the > >>>>>>> same class loader, and CustomSquare is loaded by a different class > >>>>>>> loader. I ran a fastdebug vm with the flag: -XX: > >>>>>>> +PrintSystemDictionaryAtExit. This will print out on exit, the > >>>>>>> internal vm cache of loaded classes including their class loaders. > >>>>>>> To summarize/abbreviate the scenario: > >>>>>>> class Main: // class loader 1 > >>>>>>> Printer.print((Square)CustomSquare instance); > >>>>>>> package 1, Printer.print // class loader 1 > >>>>>>> System.out.println(square.getColour()) > >>>>>>> package 1, class Square // class loader 1 > >>>>>>> public getColour() returns "blue" > >>>>>>> package 1, class customSquare // class loader 2 > >>>>>>> package private getColour() returns "red" > >>>>>>> The first question is why does the call in Printer to > >>>>>>> Square.getColour() > >>>>>>> print "red" when the class customSquare is loaded by > >>>>>>> a different class loader, but print "blue" when loaded by the > >>>>>>> same class loader. > >>>>>>> Let's start with the call in Printer. This translates to > >>>>>>> invokevirtual(...Square.getColour()) > >>>>>>> The Clarifications and Amendments to Java Virtual Machine > >>>>>>> Specification, 2nd edition definition of invokevirtual says: > >>>>>>> http://java.sun.com/docs/books/jvms/second_edition/jvms-clarify.html > >>>>>>> == > >>>>>>> The lookup algorithm used by the invokevirtual instruction (pages > >>>>>>> 291-292 of the JVMS, 2nd edition) should be revised as follows: > >>>>>>> Let C be the class of the target of the method invocation. The > >>>>>>> actual method to be invoked is selected by the following lookup > >>>>>>> procedure: > >>>>>>> If C contains a declaration for an instance method M with the > >>>>>>> same name and descriptor as the resolved method, and M overrides > >>>>>>> the resolved method , then M is the method to be invoked, and the > >>>>>>> lookup procedure terminates. > >>>>>>> Otherwise, if C has a superclass, this same lookup procedure is > >>>>>>> performed recursively using the direct superclass of C ; the > >>>>>>> method to be invoked is the result of the recursive invocation of > >>>>>>> this lookup procedure. > >>>>>>> Otherwise, an AbstractMethodError is raised. > >>>>>>> The text highlighted in red is the only change. It replaces the text > >>>>>>> and the resolved method is accessible from C > >>>>>>> in the current specification. See the revision of the definition > >>>>>>> of method override in the JLS 3rd Edition page for more details. > >>>>>>> == > >>>>>>> // First we do the static compile-time resolution using the > >>>>>>> constant pool, which in this case refers to Square.getColour() > >>>>>>> The named method is resolved (?5.4.3.3). > >>>>>>> // Then we do the dynamic run-time resolution using CustomSquare > >>>>>>> as the // target of the method invocation > >>>>>>> If C contains a declaration for an instance method M with the > >>>>>>> same name and descriptor as the resolved method, and M overrides > >>>>>>> the resolved method , then M is the method to be invoked, and the > >>>>>>> lookup procedure terminates. > >>>>>>> // The key question is: Does CustomSquare.getColour() override > >>>>>>> // Square.getColour()? > >>>>>>> // I'll get to the definitions of inherit and override in a second. > >>>>>>> // Result is: > >>>>>>> // If they use the same class loader: yes CustomSqure.getColour() > >>>>>>> overrides Square.getColour() > >>>>>>> // If they use different class loaders: no CustomSquare.getColor() > >>>>>>> does NOT override Square.getColour() > >>>>>>> * Otherwise, if C has a superclass, this same lookup procedure > >>>>>>> is performed recursively using the direct superclass of C ; the > >>>>>>> method to be invoked is the result of the recursive invocation of > >>>>>>> this lookup procedure. > >>>>>>> // If CustomSquare.getColour() does NOT override Square.getColour(), > >>>>>>> // then we use the method Square.getColour(), since Square is the > >>>>>>> // direct superclass of CustomSquare. > >>>>>>> Definitions of Inherit and Override: > >>>>>>> === > >>>>>>> Inheritance rules: JLS 3rd edition, 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 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. > >>>>>>> JLS 3rd edition 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: > >>>>>>> 1. C is a subclass of A. > >>>>>>> 2. The signature of m1 is a subsignature (?8.4.2) of the > >>>>>>> signature of m2. > >>>>>>> 3. Either > >>>>>>> o m2 is public, protected or declared with default access > >>>>>>> in the same package as C, or > >>>>>>> o 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. > >>>>>>> Note that based on the JVMS 3rd edition transitive overriding > >>>>>>> rules, we need to do an override check first for the direct > >>>>>>> superclass and if the current class does not override the direct > >>>>>>> superclass, recursively for the superclass' superclass. > >>>>>>> === > >>>>>>> So CustomSquare.getColour() does NOT override Square.getColour() > >>>>>>> because > >>>>>>> it is NOT in the same runtime package as C. > >>>>>>> =========== > >>>>>>> =========== > >>>>>>> Second question: > >>>>>>> Why do you not get an IllegalAccessException when invoking package- > >>>>>>> private CustomSquare.getColour() from Printer.print() which > >>>>>>> is in a different package? > >>>>>>> We had the same question ourselves a couple of years ago and > >>>>>>> researched this. > >>>>>>> If you look closely at JVMS 2nd edition 5.4.4 Access Controls, > >>>>>>> which goes into the details of accessibility checks for methods, > >>>>>>> read the final sentences which say: > >>>>>>> == > >>>>>>> This discussion of access control omits a related restriction on > >>>>>>> the target of a protected field access or method invocation (the > >>>>>>> target must be of class D or a subtype of D). That requirement is > >>>>>>> checked as part of the verification process (?5.4.1); it is not > >>>>>>> part of link-time access control. > >>>>>>> == > >>>>>>> The point here is that the virtual machine in the case of > >>>>>>> invokevirtual, > >>>>>>> does an accessibility check for the compile-time resolved method, > >>>>>>> Square.getColour() in your example, but does NOT perform an > >>>>>>> accessibility check on the link-time resolved method, or > >>>>>>> CustomSquare.getColour() in your example. > >>>>>>> We proposed changing this behavior, and given that it has always been > >>>>>>> this way, changing the specification and the multiple virtual > >>>>>>> machines in the field would be highly likely to break multiple > >>>>>>> shipping applications. So we decided it was not a good change > >>>>>>> to make. > >>>>>>> I hope this helps explain the current behavior, do let me > >>>>>>> know if any of this needs further clarification or if I > >>>>>>> misunderstood your original questions. > >>>>>>> thanks, > >>>>>>> Karen > >>>>>>> p.s. you can get even more explanation of the inheritance, > >>>>>>> overriding, invokevirtual, invokespecial, etc. behavior, etc. in > >>>>>>> the evaluation of the following bug: > >>>>>>> http://monaco.sfbay.sun.com/detail.jsf?cr=4766230 > >>>>>>> p.p.s. The package private discussion is under > >>>>>>> http://monaco.sfbay.sun.com/detail.jsf?cr=6810795 > >>>>>>> Jeffrey Sinclair wrote: > >>>>>>> > >>>>>>>> Karen, > >>>>>>>> > >>>>>>>> Just to say that there is one slight bug in my reproduction > >>>>>>>> (although > >>>>>>>> the result of 'Red' stays the same). > >>>>>>>> > >>>>>>>> My debug statements for which class loader the class was loaded > >>>>>>>> from is > >>>>>>>> incorrect, they are done in the constructor when they should have > >>>>>>>> been > >>>>>>>> done in a static block in the class. > >>>>>>>> > >>>>>>>> i.e. > >>>>>>>> public class Square { > >>>>>>>> static { > >>>>>>>> System.out.println("Square loaded by classloader: " + > >>>>>>>> Square.class.getClassLoader()); > >>>>>>>> } > >>>>>>>> > >>>>>>>> This will give the output: > >>>>>>>> > >>>>>>>> Printer loaded by classloader: sun.misc.Launcher > >>>>>>>> $AppClassLoader at 553f5d07 > >>>>>>>> Square loaded by classloader: sun.misc.Launcher > >>>>>>>> $AppClassLoader at 553f5d07 > >>>>>>>> CustomSquare loaded by classloader: java.net.URLClassLoader at 3ae48e1b > >>>>>>>> Red > >>>>>>>> > >>>>>>>> Which is still unexpected since I'm getting 'Red'. > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> Jeff > >>>>>>>> > >>>>>>>> On Sat, 2009-04-18 at 17:32 +0100, Jeffrey Sinclair wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> Karen, > >>>>>>>>> > >>>>>>>>> Please find attached a zip file which packages the example up > >>>>>>>>> with a > >>>>>>>>> build script that uses javac and a plain old run script. > >>>>>>>>> > >>>>>>>>> Simply run build.sh followed by run.sh (assumes that javac and > >>>>>>>>> java are > >>>>>>>>> on the PATH). > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> > >>>>>>>>> Jeff > >>>>>>>>> > >>>>>>>>> On Thu, 2009-04-16 at 17:42 -0400, Karen Kinnear wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Jeff, > >>>>>>>>>> > >>>>>>>>>> Thank you for sending me this information. I have a theory, but I > >>>>>>>>>> would be much more comfortable running the test first. I have > >>>>>>>>>> experimented > >>>>>>>>>> with this, but I'd feel much more comfortable duplicating your > >>>>>>>>>> results. > >>>>>>>>>> > >>>>>>>>>> I do appreciate you offering to package this up using plain old > >>>>>>>>>> javac/ and > >>>>>>>>>> a run script - I don't have Eclipse installed and much as I've > >>>>>>>>>> heard it > >>>>>>>>>> is a great product, I don't have the cycles to do that in the > >>>>>>>>>> near future. > >>>>>>>>>> > >>>>>>>>>> thanks so much, > >>>>>>>>>> Karen > >>>>>>>>>> > >>>>>>>>>> On Apr 14, 2009, at 5:33 PM, Jeffrey Sinclair wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Karen, > >>>>>>>>>>> > >>>>>>>>>>> Thanks for getting back to me. > >>>>>>>>>>> > >>>>>>>>>>> I was using 1.6.0_10 and have now tried 1.6.0_13 and get the same > >>>>>>>>>>> result. Specifically I've tried the following versions: > >>>>>>>>>>> > >>>>>>>>>>> java version "1.6.0_10" > >>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_10-b33) > >>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 11.0-b15, mixed mode) > >>>>>>>>>>> > >>>>>>>>>>> java version "1.6.0_13" > >>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_13-b03) > >>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed mode) > >>>>>>>>>>> > >>>>>>>>>>> I've attached my source as Eclipse projects. The URL in the > >>>>>>>>>>> main method > >>>>>>>>>>> points to the class files generated by the project with the > >>>>>>>>>>> CustomSquare. I've also added some debug info relating to > >>>>>>>>>>> which class > >>>>>>>>>>> loader is being used to load the Square, Printer and Custom > >>>>>>>>>>> Square > >>>>>>>>>>> respectively: > >>>>>>>>>>> > >>>>>>>>>>> Printer loaded by classloader: sun.misc.Launcher > >>>>>>>>>>> $AppClassLoader at 553f5d07 > >>>>>>>>>>> Square loaded by classloader: java.net.URLClassLoader at 3ae48e1b > >>>>>>>>>>> CustomSquare loaded by classloader: > >>>>>>>>>>> java.net.URLClassLoader at 3ae48e1b > >>>>>>>>>>> Red > >>>>>>>>>>> > >>>>>>>>>>> I still get Red. The key point is that the CustomSquare is not > >>>>>>>>>>> visible > >>>>>>>>>>> at all to the Printer code. If I stick the CustomSquare in the > >>>>>>>>>>> same > >>>>>>>>>>> project as Printer it will then be loaded by the > >>>>>>>>>>> AppClassLoader and I > >>>>>>>>>>> get blue. However when it is in a completely separate project > >>>>>>>>>>> and loaded > >>>>>>>>>>> via the URLClassLoader (and Printer loaded via the > >>>>>>>>>>> AppClassLoader) I > >>>>>>>>>>> always get Red. If I then change getColour() to be public in > >>>>>>>>>>> both Square > >>>>>>>>>>> and CustomSquare I get blue. > >>>>>>>>>>> > >>>>>>>>>>> This is completely baffling me. I may be doing something > >>>>>>>>>>> really silly > >>>>>>>>>>> but I can't see it :) > >>>>>>>>>>> > >>>>>>>>>>> Let me know if you can't replicate the issue with the attached > >>>>>>>>>>> Eclipse > >>>>>>>>>>> project and I'll try to package it up using plain old javac > >>>>>>>>>>> and a run > >>>>>>>>>>> script. > >>>>>>>>>>> > >>>>>>>>>>> Even if you do get blue with the different ClassLoaders for > >>>>>>>>>>> Printer and > >>>>>>>>>>> CustomSquare, I would probably argue that this is incorrect > >>>>>>>>>>> but I have > >>>>>>>>>>> to admit that this argument could be because I've > >>>>>>>>>>> misunderstood the > >>>>>>>>>>> meaning of 'runtime package' in terms of package private > >>>>>>>>>>> accessibility > >>>>>>>>>>> in the JVM spec. > >>>>>>>>>>> > >>>>>>>>>>> Jeff > >>>>>>>>>>> > >>>>>>>>>>> On Tue, 2009-04-14 at 15:30 -0400, Karen Kinnear wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> Jeff, > >>>>>>>>>>>> > >>>>>>>>>>>> Perhaps you can help me duplicate the problem. > >>>>>>>>>>>> > >>>>>>>>>>>> First - what does java -version say? > >>>>>>>>>>>> > >>>>>>>>>>>> I took the source code appended, and modified the URL setting, > >>>>>>>>>>>> which I believe should just give me your second example, i.e. > >>>>>>>>>>>> CustomSquare instantiated in a different ClassLoader than > >>>>>>>>>>>> Printer. > >>>>>>>>>>>> > >>>>>>>>>>>> When I run this with Sun's 1.6 or recent 1.7 I get "blue". > >>>>>>>>>>>> > >>>>>>>>>>>> What did we do differently? > >>>>>>>>>>>> > >>>>>>>>>>>> thanks, > >>>>>>>>>>>> Karen > >>>>>>>>>>>> > >>>>>>>>>>>> Jeffrey Sinclair wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> hotspot-dev, > >>>>>>>>>>>>> > >>>>>>>>>>>>> I've been struggling to understand why HotSpot does not > >>>>>>>>>>>>> throw an > >>>>>>>>>>>>> IllegalAccessError when a call is made to an override of a > >>>>>>>>>>>>> package > >>>>>>>>>>>>> private method on an instance loaded by a different class > >>>>>>>>>>>>> loader. I was > >>>>>>>>>>>>> hoping someone could explain to me in technical detail where > >>>>>>>>>>>>> I'm going > >>>>>>>>>>>>> wrong because it appears to be a bug. > >>>>>>>>>>>>> > >>>>>>>>>>>>> (all source code is pasted at the end of the mail) > >>>>>>>>>>>>> > >>>>>>>>>>>>> I have a class called Square with a package private method > >>>>>>>>>>>>> named > >>>>>>>>>>>>> getColour() which returns 'red'. I have a subclass of Square > >>>>>>>>>>>>> called > >>>>>>>>>>>>> CustomSquare which overrides getColour() to return 'blue'. I > >>>>>>>>>>>>> have > >>>>>>>>>>>>> another class called Printer which simply prints out > >>>>>>>>>>>>> getColour() for the > >>>>>>>>>>>>> Square passed to it. I then have two test cases: > >>>>>>>>>>>>> > >>>>>>>>>>>>> * Printer.print(Square) is called with a CustomSquare > >>>>>>>>>>>>> instantiated in > >>>>>>>>>>>>> the same ClassLoader as Printer. > >>>>>>>>>>>>> * Printer.print(Square) is called with a CustomSquare > >>>>>>>>>>>>> instantiated in > >>>>>>>>>>>>> a different ClassLoader as Printer. > >>>>>>>>>>>>> > >>>>>>>>>>>>> What I find is that I get 'blue' in the first test (as > >>>>>>>>>>>>> expected) and > >>>>>>>>>>>>> 'red' in the second test (not expected). > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> From the Access Control constraints in the Linking section > >>>>>>>>>>>>>> of the JVM > >>>>>>>>>>>>> > >>>>>>>>>>>>> specification (5.4.4), I as expecting an IllegalAccessError > >>>>>>>>>>>>> to be thrown > >>>>>>>>>>>>> because it states that a package private method is > >>>>>>>>>>>>> accessible to a class > >>>>>>>>>>>>> if it is declared by a class in the same runtime package. > >>>>>>>>>>>>> > >>>>>>>>>>>>> My understanding is that Printer is not in the same runtime > >>>>>>>>>>>>> package as > >>>>>>>>>>>>> CustomSquare which explains why my override does not kick > >>>>>>>>>>>>> in, but it > >>>>>>>>>>>>> does not explain why an IllegalAccessError is not thrown. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I was wondering if someone could explain the behaviour to me. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Regards, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Jeff > >>>>>>>>>>>>> > >>>>>>>>>>>>> The source code: > >>>>>>>>>>>>> > >>>>>>>>>>>>> public class Main { > >>>>>>>>>>>>> public static void main(String[] args) throws Exception { > >>>>>>>>>>>>> URL[] urls = new URL[]{new URL("path/to/CustomSquare")}; > >>>>>>>>>>>>> URLClassLoader loader = new URLClassLoader(urls); Class > >>>>>>>>>>>>> clazz = > >>>>>>>>>>>>> loader.loadClass("uk.co.cooljeff.visibility.CustomSquare"); > >>>>>>>>>>>>> Printer printer = new Printer(); > >>>>>>>>>>>>> printer.print((Square)clazz.newInstance()); // 'red' gets > >>>>>>>>>>>>> printed > >>>>>>>>>>>>> } } > >>>>>>>>>>>>> > >>>>>>>>>>>>> package uk.co.cooljeff.visibility; > >>>>>>>>>>>>> > >>>>>>>>>>>>> public class Printer { > >>>>>>>>>>>>> public void print(Square square) { > >>>>>>>>>>>>> System.out.println(square.getColour()); > >>>>>>>>>>>>> } > >>>>>>>>>>>>> } > >>>>>>>>>>>>> > >>>>>>>>>>>>> package uk.co.cooljeff.visibility; > >>>>>>>>>>>>> > >>>>>>>>>>>>> public class CustomSquare extends Square { > >>>>>>>>>>>>> public CustomSquare() { > >>>>>>>>>>>>> super(5); > >>>>>>>>>>>>> } > >>>>>>>>>>>>> > >>>>>>>>>>>>> @Override > >>>>>>>>>>>>> public String getColour() { > >>>>>>>>>>>>> return "blue"; > >>>>>>>>>>>>> } > >>>>>>>>>>>>> } > >>>>>>>>>>>>> > >>>>>>>>>>>>> package uk.co.cooljeff.visibility; > >>>>>>>>>>>>> > >>>>>>>>>>>>> public class Square { > >>>>>>>>>>>>> private float length; > >>>>>>>>>>>>> > >>>>>>>>>>>>> public Square(float length) { > >>>>>>>>>>>>> this.length = length; > >>>>>>>>>>>>> } > >>>>>>>>>>>>> > >>>>>>>>>>>>> public float calculateArea() { > >>>>>>>>>>>>> return length * length; > >>>>>>>>>>>>> } > >>>>>>>>>>>>> > >>>>>>>>>>>>> String getColour() { > >>>>>>>>>>>>> return "red"; > >>>>>>>>>>>>> } > >>>>>>>>>>>>> } > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>> > > From andrey.petrusenko at sun.com Mon May 4 05:20:26 2009 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Mon, 04 May 2009 12:20:26 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20090504122033.E7E62EE2B@hg.openjdk.java.net> Changeset: 2b6c55e36143 Author: tonyp Date: 2009-04-23 16:58 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2b6c55e36143 6829013: G1: set the default value of G1VerifyConcMarkPrintRechable to false Summary: Turn off G1VerifyConcMarkPrintReachable by default to minimize the amount of verbose output we generate by default. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 4753e4079a5a Author: apetrusenko Date: 2009-04-27 12:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4753e4079a5a Merge Changeset: b803b1b9e206 Author: iveresov Date: 2009-04-27 16:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b803b1b9e206 6819098: G1: reduce RSet scanning times Summary: Added a feedback-driven exponential skipping for parallel RSet scanning. Reviewed-by: tonyp, apetrusenko ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 51285b431bb2 Author: apetrusenko Date: 2009-05-04 02:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/51285b431bb2 Merge From Thomas.Rodriguez at Sun.COM Mon May 4 18:41:58 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 04 May 2009 18:41:58 -0700 Subject: review (XS) for 6837224: libsaproc.so on linux needs version of 6799141 Message-ID: http://cr.openjdk.java.net/~never/6837224 From Vladimir.Kozlov at Sun.COM Mon May 4 20:20:21 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 04 May 2009 20:20:21 -0700 Subject: review (XS) for 6837224: libsaproc.so on linux needs version of 6799141 In-Reply-To: References: Message-ID: <49FFB075.8050107@sun.com> Looks good. Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6837224 > From gnu_andrew at member.fsf.org Tue May 5 08:51:25 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 5 May 2009 16:51:25 +0100 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <49F9F971.1010404@sun.com> References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <1234768690.24153.28.camel@localhost.localdomain> <1234772748.3612.3.camel@hermans.wildebeest.org> <1234774554.11228.3.camel@localhost.localdomain> <1234862105.4062.8.camel@fedora.wildebeest.org> <499B727D.6060901@sun.com> <17c6771e0903200428j75e26899x9c15daf57f5ed20e@mail.gmail.com> <49E3ABEA.6020400@sun.com> <1241001697.4267.1.camel@fedora.wildebeest.org> <49F9F971.1010404@sun.com> Message-ID: <17c6771e0905050851u70e44df4oba96c6c7d3e1363b@mail.gmail.com> 2009/4/30 David Cox : > Mark Wielaard wrote: > > Hi Joe, > > On Mon, 2009-04-13 at 14:17 -0700, Joseph D. Darcy wrote: > > > Andrew John Hughes wrote: > > > 2009/2/18 Joe Darcy : > > > On 02/17/09 01:15 AM, Mark Wielaard wrote: > So it would be good to have an open repo that hosts the HS14 stable > build so that people interested in a stable, but modern, hotspot could > base their work on that. Since IcedTea6 is trying to standardize on HS14 > for the default hotspot and the one that Zero and Shark are based on I > could create a icedtea/hotspot repo branched from the latest HS14 code > in the jdk7/jdk7/hotspot repo. Would that be interesting to others? How > do we coordinate backporting fixes to it? Any other suggestions for > hosting an open hotspot HS14 repo (maybe as subtree of one of the other > 6 hotspot repos under jdk7/hostspot-* (I admit to not know what they are > all for currently). > > I have been talking with the HotSpot team inside Sun about the logistics > needed to support a public HotSpot Mercurial repository usable by both > OpenJDK 6 and the 6 update release, which would mean the stabilized HotSpot > 14 at this point. > > We should have something figured out relatively soon; I'll post when we do. > > > Any news on this? > > > Some news should be available real soon now... > > > Great. Do you hav any estimates on when "real soon now" will be? > > > "Real soon now" is now, finally.? We at Sun have been discussing the idea of > creating a "HotSpot Express" Project in OpenJDK through which the > stabilization of new versions of HotSpot could be managed.? We could create > repositories such as > > ? http://hg.openjdk.java.net/hsx/14/baseline > ? http://hg.openjdk.java.net/hsx/14/master > > and > > ? http://hg.openjdk.java.net/hsx/15/baseline > ? http://hg.openjdk.java.net/hsx/15/master > > in which this work would be done.? A "baseline" repo would be used to > collect suitable bug fixes from developers.? Occasionally, these changes > would be pushed to "master" to form the basis of a stable build. ? This is > the model we've used at Sun for many years.? If it seems reasonable to > folks, I'll ask one of HotSpot Group members to submit a formal project > proposal for consideration (Although I'm the manager of Sun's HotSpot > garbage collection and compiler teams,? I'm not actually a member of the > group!) > > Dave > Any idea when these repositories will appear? 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 Dalibor.Topic at Sun.COM Tue May 5 10:32:36 2009 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Tue, 05 May 2009 10:32:36 -0700 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <17c6771e0905050851u70e44df4oba96c6c7d3e1363b@mail.gmail.com> References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <1234768690.24153.28.camel@localhost.localdomain> <1234772748.3612.3.camel@hermans.wildebeest.org> <1234774554.11228.3.camel@localhost.localdomain> <1234862105.4062.8.camel@fedora.wildebeest.org> <499B727D.6060901@sun.com> <17c6771e0903200428j75e26899x9c15daf57f5ed20e@mail.gmail.com> <49E3ABEA.6020400@sun.com> <1241001697.4267.1.camel@fedora.wildebeest.org> <49F9F971.1010404@sun.com> <17c6771e0905050851u70e44df4oba96c6c7d3e1363b@mail.gmail.com> Message-ID: <4A007834.1090502@sun.com> Andrew John Hughes wrote: > Any idea when these repositories will appear? We'll need a "HotSpot Express" project proposal first. Dave, you can use one of my proposals as a template - if there is anything you need assistance with, I'm available today before 1pm and after 2pm. cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin H?ring From Erik.Trimble at Sun.COM Tue May 5 12:26:59 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Tue, 05 May 2009 12:26:59 -0700 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <4A007834.1090502@sun.com> References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <1234768690.24153.28.camel@localhost.localdomain> <1234772748.3612.3.camel@hermans.wildebeest.org> <1234774554.11228.3.camel@localhost.localdomain> <1234862105.4062.8.camel@fedora.wildebeest.org> <499B727D.6060901@sun.com> <17c6771e0903200428j75e26899x9c15daf57f5ed20e@mail.gmail.com> <49E3ABEA.6020400@sun.com> <1241001697.4267.1.camel@fedora.wildebeest.org> <49F9F971.1010404@sun.com> <17c6771e0905050851u70e44df4oba96c6c7d3e1363b@mail.gmail.com> <4A007834.1090502@sun.com> Message-ID: <4A009303.9070607@sun.com> Dalibor Topic wrote: > Andrew John Hughes wrote: > >> Any idea when these repositories will appear? >> > > We'll need a "HotSpot Express" project proposal first. > > Dave, you can use one of my proposals as a template - > if there is anything you need assistance with, I'm > available today before 1pm and after 2pm. > > cheers, > dalibor topic > Dave's on vacation until Thursday. I'll likely be putting the project proposal out as soon as he comes back (i.e. no later than Friday). -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From martinrb at google.com Tue May 5 14:10:34 2009 From: martinrb at google.com (Martin Buchholz) Date: Tue, 5 May 2009 14:10:34 -0700 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <4A007834.1090502@sun.com> References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <1234774554.11228.3.camel@localhost.localdomain> <1234862105.4062.8.camel@fedora.wildebeest.org> <499B727D.6060901@sun.com> <17c6771e0903200428j75e26899x9c15daf57f5ed20e@mail.gmail.com> <49E3ABEA.6020400@sun.com> <1241001697.4267.1.camel@fedora.wildebeest.org> <49F9F971.1010404@sun.com> <17c6771e0905050851u70e44df4oba96c6c7d3e1363b@mail.gmail.com> <4A007834.1090502@sun.com> Message-ID: <1ccfd1c10905051410h255d7ecbt386b8e87340646d9@mail.gmail.com> On Tue, May 5, 2009 at 10:32, Dalibor Topic wrote: > Andrew John Hughes wrote: >> Any idea when these repositories will appear? > > We'll need a "HotSpot Express" project proposal first. I don't see why we need a "project". There's already all kinds of hotspot forests on http://hg.openjdk.java.net/ that don't have any associated formal project. I suggest that the current maintainer of the openjdk public forests (Erik, perhaps) just go ahead and create the new repos with whatever name you want (e.g. "hotspot-14"). Martin From gnu_andrew at member.fsf.org Tue May 5 14:46:00 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 5 May 2009 22:46:00 +0100 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <1ccfd1c10905051410h255d7ecbt386b8e87340646d9@mail.gmail.com> References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <1234862105.4062.8.camel@fedora.wildebeest.org> <499B727D.6060901@sun.com> <17c6771e0903200428j75e26899x9c15daf57f5ed20e@mail.gmail.com> <49E3ABEA.6020400@sun.com> <1241001697.4267.1.camel@fedora.wildebeest.org> <49F9F971.1010404@sun.com> <17c6771e0905050851u70e44df4oba96c6c7d3e1363b@mail.gmail.com> <4A007834.1090502@sun.com> <1ccfd1c10905051410h255d7ecbt386b8e87340646d9@mail.gmail.com> Message-ID: <17c6771e0905051446i35c9192bi33eb18d76e3b6e35@mail.gmail.com> 2009/5/5 Martin Buchholz : > On Tue, May 5, 2009 at 10:32, Dalibor Topic wrote: >> Andrew John Hughes wrote: >>> Any idea when these repositories will appear? >> >> We'll need a "HotSpot Express" project proposal first. > > I don't see why we need a "project". > There's already all kinds of hotspot forests on > http://hg.openjdk.java.net/ > that don't have any associated formal project. > > I suggest that the current maintainer of > the openjdk public forests (Erik, perhaps) > just go ahead and create the new repos > with whatever name you want > (e.g. "hotspot-14"). > > Martin > It does seem like a bit too much bureaucracy. We've already been waiting three months for 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 mark at klomp.org Wed May 6 00:36:13 2009 From: mark at klomp.org (Mark Wielaard) Date: Wed, 06 May 2009 09:36:13 +0200 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <17c6771e0905051446i35c9192bi33eb18d76e3b6e35@mail.gmail.com> References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <1234862105.4062.8.camel@fedora.wildebeest.org> <499B727D.6060901@sun.com> <17c6771e0903200428j75e26899x9c15daf57f5ed20e@mail.gmail.com> <49E3ABEA.6020400@sun.com> <1241001697.4267.1.camel@fedora.wildebeest.org> <49F9F971.1010404@sun.com> <17c6771e0905050851u70e44df4oba96c6c7d3e1363b@mail.gmail.com> <4A007834.1090502@sun.com> <1ccfd1c10905051410h255d7ecbt386b8e87340646d9@mail.gmail.com> <17c6771e0905051446i35c9192bi33eb18d76e3b6e35@mail.gmail.com> Message-ID: <1241595373.2374.7.camel@fedora.wildebeest.org> Hi, On Tue, 2009-05-05 at 22:46 +0100, Andrew John Hughes wrote: > 2009/5/5 Martin Buchholz : > > On Tue, May 5, 2009 at 10:32, Dalibor Topic wrote: > >> Andrew John Hughes wrote: > >>> Any idea when these repositories will appear? > >> > >> We'll need a "HotSpot Express" project proposal first. > > > > I don't see why we need a "project". > > There's already all kinds of hotspot forests on > > http://hg.openjdk.java.net/ > > that don't have any associated formal project. > > > > I suggest that the current maintainer of > > the openjdk public forests (Erik, perhaps) > > just go ahead and create the new repos > > with whatever name you want > > (e.g. "hotspot-14"). > > It does seem like a bit too much bureaucracy. We've already been > waiting three months for this. I agree that going through the whole formal project proposal, voting, etc. seems a bit heavy-weight for something like this. hotspot already has 5 repos. This will just be a stabilization branch. In IcedTea we let everybody make release branches whenever they want to stabilize things (under /hg/release/), or create personal branches (under /people//) whenever they want to do some experimentation. That makes it so that all stabilization or experimentation is easy to do in public and share with everybody. Cheers, Mark From mr at sun.com Wed May 6 08:09:28 2009 From: mr at sun.com (Mark Reinhold) Date: Wed, 06 May 2009 08:09:28 -0700 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: mark@klomp.org; Wed, 06 May 2009 09:36:13 +0200; <1241595373.2374.7.camel@fedora.wildebeest.org> Message-ID: <20090506150928.5999A5591@eggemoggin.niobe.net> Thanks for all the feedback. In order to move this forward, I'll go ahead and create the proposed forests on hg.openjdk.java.net. In the fullness of time I still think there's value in having a HotSpot Express Project. Those of us who've been involved in this discussion will understand what's going on, but it'd be good to have an obvious place where people new to the topic can find documentation. - Mark From keith.mcguigan at sun.com Thu May 7 12:56:29 2009 From: keith.mcguigan at sun.com (keith.mcguigan at sun.com) Date: Thu, 07 May 2009 19:56:29 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20090507195651.CC8A1E566@hg.openjdk.java.net> Changeset: 81a249214991 Author: poonam Date: 2009-05-04 17:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/81a249214991 6829234: Refix 6822407 and 6812971 Summary: Fixes two SA issues 6822407 and 6812971 Reviewed-by: swamyv, acorn, kvn, coleenp ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java Changeset: c8f1f4de26c9 Author: kamg Date: 2009-05-07 11:44 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c8f1f4de26c9 Merge From john.coomes at sun.com Thu May 7 16:22:28 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Thu, 07 May 2009 23:22:28 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20090507232237.B3E7EE59C@hg.openjdk.java.net> Changeset: 20c6f43950b5 Author: johnc Date: 2009-04-30 15:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/20c6f43950b5 6490395: G1: Tidy up command line flags. Summary: Change G1 flag names to be more consistent and disable some in 'product' mode. Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: a2957df801a1 Author: johnc Date: 2009-05-05 22:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a2957df801a1 6833576: G1: assert illegal index, growableArray.hpp:186 Summary: The code that calculates the heap region index for an object address incorrectly used signed arithmetic. Reviewed-by: jcoomes, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp Changeset: a58ad611cc63 Author: jcoomes Date: 2009-05-07 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a58ad611cc63 Merge From vladimir.kozlov at sun.com Thu May 7 21:11:57 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 08 May 2009 04:11:57 +0000 Subject: hg: jdk7/hotspot/hotspot: 5 new changesets Message-ID: <20090508041208.2B45AE5C6@hg.openjdk.java.net> Changeset: 2b25645dab33 Author: never Date: 2009-05-04 22:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2b25645dab33 6837224: libsaproc.so on linux needs version of 6799141 Reviewed-by: kvn ! agent/src/os/linux/Makefile Changeset: 36ee9b69616e Author: cfang Date: 2009-05-05 11:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/36ee9b69616e 6833879: Assigning positive zero is ignored when old value is negative zero Summary: Don't perform CMOVE identity optimization for floating point types Reviewed-by: kvn, never ! src/share/vm/opto/connode.cpp Changeset: cecd04fc6f93 Author: twisti Date: 2009-05-06 12:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cecd04fc6f93 6837011: SIGSEGV in PhaseIdealLoop in 32bit jvm Summary: The CR's test crashes with SIGSEGV when running with "-server -Xcomp" using using 32bit jvm. Reviewed-by: kvn, never, rasbold ! src/share/vm/opto/divnode.cpp + test/compiler/6837011/Test6837011.java Changeset: f96f285ed3dd Author: never Date: 2009-05-06 17:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f96f285ed3dd 6838154: make/linux/makefiles/sa.make needs hash-style fix Reviewed-by: kvn, jrose ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make Changeset: 9b3a41ccc927 Author: kvn Date: 2009-05-07 17:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9b3a41ccc927 Merge From gbenson at redhat.com Fri May 8 09:14:41 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 8 May 2009 17:14:41 +0100 Subject: Review Request: 6812511: Allow Interpreter-only builds Message-ID: <20090508161440.GK3190@redhat.com> Hi all, I have a patch that's been sitting in the bug databases for a while: https://bugs.openjdk.java.net/show_bug.cgi?id=100011 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6812511 It allows HotSpot to be built interpreter-only, which is required for the Zero assembler port. It touches both the hotspot and the jdk forests, so it may need approval from someone in both teams. Christian Thalinger (twisti) said that someone (Kelly?) told him verbally it was fine to commit a while back, but it was a month or so ago and can't remember exactly what was said. I have push access (I think -- I've not tried it out yet!) but I don't want to commit it while it's ambiguous like this. Cheers, Gary -- http://gbenson.net/ From martinrb at google.com Fri May 8 09:47:03 2009 From: martinrb at google.com (Martin Buchholz) Date: Fri, 8 May 2009 09:47:03 -0700 Subject: Review Request: 6812511: Allow Interpreter-only builds In-Reply-To: <20090508161440.GK3190@redhat.com> References: <20090508161440.GK3190@redhat.com> Message-ID: <1ccfd1c10905080947n10b45f0dk7f96916e8a91d16b@mail.gmail.com> [+build-dev] Not that it matters much, but build-dev is a better list for this patch than core-libs-dev. Martin On Fri, May 8, 2009 at 09:14, Gary Benson wrote: > Hi all, > > I have a patch that's been sitting in the bug databases for a while: > > ?https://bugs.openjdk.java.net/show_bug.cgi?id=100011 > ?http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6812511 > > It allows HotSpot to be built interpreter-only, which is required > for the Zero assembler port. ?It touches both the hotspot and the > jdk forests, so it may need approval from someone in both teams. > Christian Thalinger (twisti) said that someone (Kelly?) told him > verbally it was fine to commit a while back, but it was a month > or so ago and can't remember exactly what was said. ?I have push > access (I think -- I've not tried it out yet!) but I don't want > to commit it while it's ambiguous like this. > > Cheers, > Gary > > -- > http://gbenson.net/ > From Kelly.Ohair at Sun.COM Fri May 8 12:01:24 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 08 May 2009 12:01:24 -0700 Subject: Need reviewer - small type error found by VS2008 on 64bit Windows Message-ID: <4A048184.205@sun.com> Need reviewer - small type error found by VS2008 on 64bit Windows 6839126: Type error found by newer windows compiler http://cr.openjdk.java.net/~ohair/jdk7/6839126-hotspot-psdk-type/webrev/ Definitely minor and not for m3. Just need to get the jdk7/build forest in a state that it can be built by the 64bit Windows SDK v6.1 (VS2008 compilers) again. May push this changeset to jdk7/build/hotspot so we can proceed with this Windows compiler upgrade work, will also push the changeset to the jdk7/hotspot/hotspot repository once we get past this m3 madness... 8^} -kto From Kelly.Ohair at Sun.COM Fri May 8 12:20:50 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 08 May 2009 12:20:50 -0700 Subject: Need reviewer - add test to make sure xshare:dump always works Message-ID: <4A048612.1080604@sun.com> Addition of a testcase to our JPRT system to make sure -Xshare:dump and misc command line options work (i.e. don't create non-zero exit conditions :^) on every build of hotspot. 6839151: Add a JPRT default test of -Xshare:dump when new hotspot is built http://cr.openjdk.java.net/~ohair/jdk7/6839151-hotspot-xshare-test/webrev/ This could catch some of the problems seen with class data sharing in the past, and allows for adding future command line checks. -kto From Thomas.Rodriguez at Sun.COM Fri May 8 12:42:16 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 08 May 2009 12:42:16 -0700 Subject: Need reviewer - add test to make sure xshare:dump always works In-Reply-To: <4A048612.1080604@sun.com> References: <4A048612.1080604@sun.com> Message-ID: looks good to me. tom On May 8, 2009, at 12:20 PM, Kelly O'Hair wrote: > > Addition of a testcase to our JPRT system to make sure -Xshare:dump > and > misc command line options work (i.e. don't create non-zero exit > conditions :^) > on every build of hotspot. > > 6839151: Add a JPRT default test of -Xshare:dump when new hotspot is > built > http://cr.openjdk.java.net/~ohair/jdk7/6839151-hotspot-xshare-test/webrev/ > > This could catch some of the problems seen with class data sharing > in the > past, and allows for adding future command line checks. > > -kto From Thomas.Rodriguez at Sun.COM Fri May 8 12:44:03 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 08 May 2009 12:44:03 -0700 Subject: Need reviewer - small type error found by VS2008 on 64bit Windows In-Reply-To: <4A048184.205@sun.com> References: <4A048184.205@sun.com> Message-ID: <657BE547-833A-4695-9B18-BB70C1C92282@sun.com> seems ok. tom On May 8, 2009, at 12:01 PM, Kelly O'Hair wrote: > > Need reviewer - small type error found by VS2008 on 64bit Windows > > 6839126: Type error found by newer windows compiler > http://cr.openjdk.java.net/~ohair/jdk7/6839126-hotspot-psdk-type/webrev/ > > Definitely minor and not for m3. > Just need to get the jdk7/build forest in a state that it can be built > by the 64bit Windows SDK v6.1 (VS2008 compilers) again. > May push this changeset to jdk7/build/hotspot so we can proceed with > this > Windows compiler upgrade work, will also push the changeset to the > jdk7/hotspot/hotspot repository once we get past this m3 madness... > 8^} > > -kto > From Vladimir.Kozlov at Sun.COM Fri May 8 12:55:46 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 08 May 2009 12:55:46 -0700 Subject: Need reviewer - small type error found by VS2008 on 64bit Windows In-Reply-To: <4A048184.205@sun.com> References: <4A048184.205@sun.com> Message-ID: <4A048E42.5080402@sun.com> Looks good. Vladimir Kelly O'Hair wrote: > > Need reviewer - small type error found by VS2008 on 64bit Windows > > 6839126: Type error found by newer windows compiler > http://cr.openjdk.java.net/~ohair/jdk7/6839126-hotspot-psdk-type/webrev/ > > Definitely minor and not for m3. > Just need to get the jdk7/build forest in a state that it can be built > by the 64bit Windows SDK v6.1 (VS2008 compilers) again. > May push this changeset to jdk7/build/hotspot so we can proceed with this > Windows compiler upgrade work, will also push the changeset to the > jdk7/hotspot/hotspot repository once we get past this m3 madness... 8^} > > -kto > From igor.veresov at sun.com Fri May 8 18:22:56 2009 From: igor.veresov at sun.com (igor.veresov at sun.com) Date: Sat, 09 May 2009 01:22:56 +0000 Subject: hg: jdk7/hotspot/hotspot: 6838842: NUMA allocator: Segfault during startup on Linux Message-ID: <20090509012304.6F876E885@hg.openjdk.java.net> Changeset: 622212a69394 Author: iveresov Date: 2009-05-08 15:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/622212a69394 6838842: NUMA allocator: Segfault during startup on Linux Summary: Restored os::free_memory() semantics Reviewed-by: apetrusenko ! src/os/linux/vm/os_linux.cpp From danhicks at ieee.org Sun May 10 12:57:27 2009 From: danhicks at ieee.org (Dan Hicks) Date: Sun, 10 May 2009 14:57:27 -0500 Subject: StackMap documentation In-Reply-To: References: Message-ID: <4A0731A7.6020107@ieee.org> I'm kicking myself -- I apparently tossed my marked-up copy of the StackMap section of the JVM spec when I left my previous job. Now I can't find ANY copy online, much less one with corrections. Is that spec online somewhere? And which forum is the right one to go to for info on it? -- Dan Hicks All we know is still infinitely less than all that still remains unknown. From David.Holmes at Sun.COM Sun May 10 15:02:14 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Mon, 11 May 2009 08:02:14 +1000 Subject: StackMap documentation In-Reply-To: <4A0731A7.6020107@ieee.org> References: <4A0731A7.6020107@ieee.org> Message-ID: <4A074EE6.70208@sun.com> Dan, I don't know if it contains what you need, but the online JVMS is here: http://java.sun.com/docs/books/jvms/ Cheers, David Holmes Dan Hicks said the following on 05/11/09 05:57: > I'm kicking myself -- I apparently tossed my marked-up copy of the > StackMap section of the JVM spec when I left my previous job. Now I > can't find ANY copy online, much less one with corrections. Is that > spec online somewhere? And which forum is the right one to go to for > info on it? > From David.Holmes at Sun.COM Sun May 10 15:59:33 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Mon, 11 May 2009 08:59:33 +1000 Subject: StackMap documentation In-Reply-To: <4A074EE6.70208@sun.com> References: <4A0731A7.6020107@ieee.org> <4A074EE6.70208@sun.com> Message-ID: <4A075C55.80006@sun.com> FYI the draft chapter update referred to is available form the JSR-202 download page on jcp.org David David Holmes - Sun Microsystems said the following on 05/11/09 08:02: > Dan, > > I don't know if it contains what you need, but the online JVMS is here: > > http://java.sun.com/docs/books/jvms/ > > Cheers, > David Holmes > > Dan Hicks said the following on 05/11/09 05:57: >> I'm kicking myself -- I apparently tossed my marked-up copy of the >> StackMap section of the JVM spec when I left my previous job. Now I >> can't find ANY copy online, much less one with corrections. Is that >> spec online somewhere? And which forum is the right one to go to for >> info on it? >> From gbenson at redhat.com Mon May 11 00:32:50 2009 From: gbenson at redhat.com (Gary Benson) Date: Mon, 11 May 2009 08:32:50 +0100 Subject: Review Request: 6812511: Allow Interpreter-only builds In-Reply-To: <1ccfd1c10905080947n10b45f0dk7f96916e8a91d16b@mail.gmail.com> References: <20090508161440.GK3190@redhat.com> <1ccfd1c10905080947n10b45f0dk7f96916e8a91d16b@mail.gmail.com> Message-ID: <20090511073249.GA3204@redhat.com> Ah, thank you. Cheers, Gary Martin Buchholz wrote: > [+build-dev] > > Not that it matters much, but build-dev is a better list for this > patch than core-libs-dev. > > Martin > > On Fri, May 8, 2009 at 09:14, Gary Benson wrote: > > Hi all, > > > > I have a patch that's been sitting in the bug databases for a while: > > > > ?https://bugs.openjdk.java.net/show_bug.cgi?id=100011 > > ?http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6812511 > > > > It allows HotSpot to be built interpreter-only, which is required > > for the Zero assembler port. ?It touches both the hotspot and the > > jdk forests, so it may need approval from someone in both teams. > > Christian Thalinger (twisti) said that someone (Kelly?) told him > > verbally it was fine to commit a while back, but it was a month > > or so ago and can't remember exactly what was said. ?I have push > > access (I think -- I've not tried it out yet!) but I don't want > > to commit it while it's ambiguous like this. > > > > Cheers, > > Gary > > > > -- > > http://gbenson.net/ From omajid at redhat.com Tue May 12 07:50:31 2009 From: omajid at redhat.com (Omair Majid) Date: Tue, 12 May 2009 10:50:31 -0400 Subject: Request for approval: Backport fix for Bug 6539464 to HS14 Message-ID: <4A098CB7.6040500@redhat.com> Hi, The current Hotspot 14 stable has an issue where successive calls to Math.log() produce inconsistent results. The original bug is at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6539464. A fix was committed to openjdk7 http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/819880572f09. Is it OK to backport this fix to hotspot 14? Cheers, Omair From igor.veresov at sun.com Tue May 12 18:17:21 2009 From: igor.veresov at sun.com (igor.veresov at sun.com) Date: Wed, 13 May 2009 01:17:21 +0000 Subject: hg: jdk7/hotspot/hotspot: 6840196: NUMA allocator: crash in fastdebug during startup on Linux Message-ID: <20090513011727.2776AEB51@hg.openjdk.java.net> Changeset: cf71f149d7ae Author: iveresov Date: 2009-05-12 15:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cf71f149d7ae 6840196: NUMA allocator: crash in fastdebug during startup on Linux Summary: With libnuma >1.2 explicity use 1.1 symbols Reviewed-by: ysr ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp From mark at klomp.org Wed May 13 00:44:22 2009 From: mark at klomp.org (Mark Wielaard) Date: Wed, 13 May 2009 09:44:22 +0200 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <20090506150928.5999A5591@eggemoggin.niobe.net> References: <20090506150928.5999A5591@eggemoggin.niobe.net> Message-ID: <1242200662.3636.6.camel@hermans.wildebeest.org> Hi Mark, On Wed, 2009-05-06 at 08:09 -0700, Mark Reinhold wrote: > In order to move this forward, I'll go ahead and create the proposed > forests on hg.openjdk.java.net. Thanks, how are they called and are they already populated? I believe Lillian is holding up the IcedTea 1.5 release for this since that is (since 1.4) already based on hs14 and it would be good to make sure that instead of a jdk7/hotspot snapshot it would use the proper public hs14 repo. There are also people with pending patches against it that they would like to move upstream. > In the fullness of time I still think there's value in having a HotSpot > Express Project. Those of us who've been involved in this discussion > will understand what's going on, but it'd be good to have an obvious > place where people new to the topic can find documentation. There was a vote started to create a separate express project, but then aborted because of procedural issues (wrong mailinglist). It is unclear whether or not the project creation is stuck now. Cheers, Mark From erik.trimble at sun.com Wed May 13 09:03:21 2009 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Wed, 13 May 2009 16:03:21 +0000 Subject: hg: jdk7/hotspot/hotspot: 7 new changesets Message-ID: <20090513160334.53A5FED05@hg.openjdk.java.net> Changeset: 53d9bf689e80 Author: xdono Date: 2009-04-30 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/53d9bf689e80 Added tag jdk7-b57 for changeset f4cbf78110c7 ! .hgtags Changeset: 8078631685e4 Author: trims Date: 2009-05-07 21:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8078631685e4 Merge - make/jprt.config Changeset: fede134842ab Author: trims Date: 2009-05-07 21:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fede134842ab 6838819: Bump the HS16 build number to 03 Summary: Update the HS16 build number to 03 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 7e1dbef51011 Author: trims Date: 2009-05-08 19:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7e1dbef51011 Merge Changeset: 07c1c01e0315 Author: trims Date: 2009-05-13 08:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/07c1c01e0315 Merge Changeset: 313b56165de7 Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/313b56165de7 Added tag jdk7-b58 for changeset 53d9bf689e80 ! .hgtags Changeset: c55be0c7bd32 Author: trims Date: 2009-05-13 08:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c55be0c7bd32 Merge From Thomas.Rodriguez at Sun.COM Wed May 13 10:51:42 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 13 May 2009 10:51:42 -0700 Subject: Request for approval: Backport fix for Bug 6539464 to HS14 In-Reply-To: <4A098CB7.6040500@redhat.com> References: <4A098CB7.6040500@redhat.com> Message-ID: <8346A602-D84F-4EF9-AC4A-5E7338B2CBA6@sun.com> I'm not sure what you're requesting here. I don't think this can make it into the current hs14 which is going out in 6u14. I think that's pretty much in the can. It could certainly be backported in a later release and there's no reason it couldn't get into 6 open once that's updated to hs14. It should backport cleanly without problem. tom On May 12, 2009, at 7:50 AM, Omair Majid wrote: > Hi, > > The current Hotspot 14 stable has an issue where successive calls to > Math.log() produce inconsistent results. The original bug is at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6539464 > . > > A fix was committed to openjdk7 http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/819880572f09 > . Is it OK to backport this fix to hotspot 14? > > Cheers, > Omair From gnu_andrew at member.fsf.org Wed May 13 11:04:37 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 13 May 2009 19:04:37 +0100 Subject: Request for approval: Backport fix for Bug 6539464 to HS14 In-Reply-To: <8346A602-D84F-4EF9-AC4A-5E7338B2CBA6@sun.com> References: <4A098CB7.6040500@redhat.com> <8346A602-D84F-4EF9-AC4A-5E7338B2CBA6@sun.com> Message-ID: <17c6771e0905131104n50104ebcn902530e3a536d628@mail.gmail.com> 2009/5/13 Tom Rodriguez : > I'm not sure what you're requesting here. ?I don't think this can make it > into the current hs14 which is going out in 6u14. ?I think that's pretty > much in the can. ?It could certainly be backported in a later release and > there's no reason it couldn't get into 6 open once that's updated to hs14. > ?It should backport cleanly without problem. > > tom > > On May 12, 2009, at 7:50 AM, Omair Majid wrote: > >> Hi, >> >> The current Hotspot 14 stable has an issue where successive calls to >> Math.log() produce inconsistent results. The original bug is at >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6539464. >> >> A fix was committed to openjdk7 >> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/819880572f09. Is it >> OK to backport this fix to hotspot 14? >> >> Cheers, >> Omair > > As this is an OpenJDK mailing list, it seems clear (at least to me) that the intention was to make this available in OpenJDK, not a proprietary Sun build. I believe a hs14 forest has been proposed and should be making an appearance on hg.openjdk.java.net at some point... (http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-May/001623.html). The backport Omair mentions has already been completed and the patch applied locally in IcedTea. The intention behind this mail was to make sure the patch also gets applied upstream. -- 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 Wed May 13 13:59:10 2009 From: mr at sun.com (Mark Reinhold) Date: Wed, 13 May 2009 13:59:10 -0700 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: mark@klomp.org; Wed, 13 May 2009 09:44:22 +0200; <1242200662.3636.6.camel@hermans.wildebeest.org> Message-ID: <20090513205910.247D95CE0@eggemoggin.niobe.net> > Date: Wed, 13 May 2009 09:44:22 +0200 > From: Mark Wielaard > On Wed, 2009-05-06 at 08:09 -0700, Mark Reinhold wrote: >> In order to move this forward, I'll go ahead and create the proposed >> forests on hg.openjdk.java.net. > > Thanks, how are they called and are they already populated? http://hg.openjdk.java.net/hsx/hsx14/baseline http://hg.openjdk.java.net/hsx/hsx14/master (I don't know why the tip changeset in each of these repos is labeled "6836332: Bump Hotspot 14 build number to 15", which seems odd.) >> In the fullness of time I still think there's value in having a HotSpot >> Express Project. Those of us who've been involved in this discussion >> will understand what's going on, but it'd be good to have an obvious >> place where people new to the topic can find documentation. > > There was a vote started to create a separate express project, but then > aborted because of procedural issues (wrong mailinglist). It is unclear > whether or not the project creation is stuck now. Not aborted, just delayed. Dalibor is assisting. - Mark From Erik.Trimble at Sun.COM Wed May 13 14:04:15 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Wed, 13 May 2009 14:04:15 -0700 Subject: CFV: Project Sponsorship: Hotspot Express Message-ID: <4A0B35CF.8050502@sun.com> Question: Should the Hotspot Group sponsor the proposed Hotspot Express [1] Project? Please cast your vote by replying, publicly, to this message with either Vote: yes or Vote: no as the first line of the message body. You may, at your option, indicate the reason for your decision on subsequent lines. Votes must be cast in the open; votes sent as private replies will not be counted. The sponsorship decision will be made by a simple majority vote of the Group's Members. Votes are due by midnight UTC a week from Friday, the 22nd of May. As an optimization, if an absolute majority of the Group's Members votes one way or the other prior to that time then the decision may be rendered earlier. Only Members of the Hotspot Group are eligible to vote on this decision. The current Members are: Andrei Pangin Andrey Petrusenko Antonios Printezis Chuck Rasbold Coleen Phillimore Chris Phillips Daniel Daugherty Dave Dice David Holmes Erik Trimble Igor Veresov Ivan Krylov James Melvin Jim Holmlund John Coomes John Rose Jon Masamitsu Karen Kinnear Keith McGuigan Kenneth Russell Kevin Walls Laurent Daynes Lev Serebryakov Paul Hohensee Peter Kessler Stephen Bohne Thomas Rodriguez Vladimir Kozlov Xiaobin Lu Y S Ramakrishna Yumin Qi Once a decision has been made the votes will be summarized and reported to this list and also to discuss at openjdk.java.net. [1] See: http://mail.openjdk.java.net/pipermail/announce/2009-May/000076.html -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From mr at sun.com Wed May 13 14:05:29 2009 From: mr at sun.com (Mark Reinhold) Date: Wed, 13 May 2009 14:05:29 -0700 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: mr@sun.com; Wed, 13 May 2009 13:59:10 PDT; <20090513205910.247D95CE0@eggemoggin.niobe.net> Message-ID: <20090513210529.917DC5CE0@eggemoggin.niobe.net> > From: Mark Reinhold > Date: Wed, 13 May 2009 13:59:10 -0700 > ... > > http://hg.openjdk.java.net/hsx/hsx14/baseline > http://hg.openjdk.java.net/hsx/hsx14/master > > (I don't know why the tip changeset in each of these repos is labeled > "6836332: Bump Hotspot 14 build number to 15", which seems odd.) Duh, my confusion. It's just the build number (s/b14/b15/) rather than the HotSpot major version number, which remains at 14. Nevermind. - Mark From rasbold at google.com Wed May 13 14:10:35 2009 From: rasbold at google.com (Chuck Rasbold) Date: Wed, 13 May 2009 14:10:35 -0700 Subject: CFV: Project Sponsorship: Hotspot Express In-Reply-To: <4A0B35CF.8050502@sun.com> References: <4A0B35CF.8050502@sun.com> Message-ID: <4149a0430905131410h72396a68y1b854b8a893a9331@mail.gmail.com> Vote: yes On Wed, May 13, 2009 at 2:04 PM, Erik Trimble wrote: > Question: Should the Hotspot Group sponsor the proposed Hotspot Express [1] > Project? > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC a week from Friday, > the 22nd of May. As an optimization, if an absolute majority of the > Group's Members votes one way or the other prior to that time then > the decision may be rendered earlier. > > Only Members of the Hotspot Group are eligible to vote on this > decision. The current Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Laurent Daynes > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > Once a decision has been made the votes will be summarized and > reported to this list and also to discuss at openjdk.java.net. < > http://mail.openjdk.java.net/mailman/listinfo/porters-dev> > > > [1] See: > http://mail.openjdk.java.net/pipermail/announce/2009-May/000076.html > > -- > Erik Trimble > Java System Support > Mailstop: usca22-123 > Phone: x17195 > Santa Clara, CA > Timezone: US/Pacific (GMT-0800) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090513/a6c6c152/attachment.html From gnu_andrew at member.fsf.org Wed May 13 14:10:49 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 13 May 2009 22:10:49 +0100 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <20090513210529.917DC5CE0@eggemoggin.niobe.net> References: <20090513205910.247D95CE0@eggemoggin.niobe.net> <20090513210529.917DC5CE0@eggemoggin.niobe.net> Message-ID: <17c6771e0905131410n37a8723bq2dcb3e20eded5064@mail.gmail.com> 2009/5/13 Mark Reinhold : >> From: Mark Reinhold >> Date: Wed, 13 May 2009 13:59:10 -0700 > >> ... >> >> http://hg.openjdk.java.net/hsx/hsx14/baseline >> http://hg.openjdk.java.net/hsx/hsx14/master >> >> (I don't know why the tip changeset in each of these repos is labeled >> ?"6836332: Bump Hotspot 14 build number to 15", which seems odd.) > > Duh, my confusion. ?It's just the build number (s/b14/b15/) rather than > the HotSpot major version number, which remains at 14. > > Nevermind. > > - Mark > Hurrah!!!! -- 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 Wed May 13 14:12:50 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Wed, 13 May 2009 15:12:50 -0600 Subject: CFV: Project Sponsorship: Hotspot Express In-Reply-To: <4A0B35CF.8050502@sun.com> References: <4A0B35CF.8050502@sun.com> Message-ID: <4A0B37D2.9080705@sun.com> Yes. Erik Trimble wrote: > Question: Should the Hotspot Group sponsor the proposed Hotspot > Express [1] Project? > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC a week from Friday, > the 22nd of May. As an optimization, if an absolute majority of the > Group's Members votes one way or the other prior to that time then > the decision may be rendered earlier. > > Only Members of the Hotspot Group are eligible to vote on this > decision. The current Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Laurent Daynes > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > Once a decision has been made the votes will be summarized and > reported to this list and also to discuss at openjdk.java.net. > > > > [1] See: > http://mail.openjdk.java.net/pipermail/announce/2009-May/000076.html > From Daniel.Daugherty at Sun.COM Wed May 13 14:18:04 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Wed, 13 May 2009 15:18:04 -0600 Subject: CFV: Project Sponsorship: Hotspot Express In-Reply-To: <4A0B35CF.8050502@sun.com> References: <4A0B35CF.8050502@sun.com> Message-ID: <4A0B390C.7020406@sun.com> Vote: yes Erik Trimble wrote: > Question: Should the Hotspot Group sponsor the proposed Hotspot > Express [1] Project? > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC a week from Friday, > the 22nd of May. As an optimization, if an absolute majority of the > Group's Members votes one way or the other prior to that time then > the decision may be rendered earlier. > > Only Members of the Hotspot Group are eligible to vote on this > decision. The current Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Laurent Daynes > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > Once a decision has been made the votes will be summarized and > reported to this list and also to discuss at openjdk.java.net. > > > > [1] See: > http://mail.openjdk.java.net/pipermail/announce/2009-May/000076.html > From Igor.Veresov at Sun.COM Wed May 13 14:19:28 2009 From: Igor.Veresov at Sun.COM (Igor Veresov) Date: Wed, 13 May 2009 14:19:28 -0700 Subject: CFV: Project Sponsorship: Hotspot Express In-Reply-To: <4A0B35CF.8050502@sun.com> References: <4A0B35CF.8050502@sun.com> Message-ID: <4A0B3960.3090307@sun.com> Vote: yes On 5/13/09 2:04 PM, Erik Trimble wrote: > Question: Should the Hotspot Group sponsor the proposed Hotspot Express > [1] Project? > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC a week from Friday, > the 22nd of May. As an optimization, if an absolute majority of the > Group's Members votes one way or the other prior to that time then > the decision may be rendered earlier. > > Only Members of the Hotspot Group are eligible to vote on this > decision. The current Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Laurent Daynes > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > Once a decision has been made the votes will be summarized and > reported to this list and also to discuss at openjdk.java.net. > > > > [1] See: > http://mail.openjdk.java.net/pipermail/announce/2009-May/000076.html > From Y.S.Ramakrishna at Sun.COM Wed May 13 14:19:59 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Wed, 13 May 2009 14:19:59 -0700 Subject: CFV: Project Sponsorship: Hotspot Express In-Reply-To: <4A0B35CF.8050502@sun.com> References: <4A0B35CF.8050502@sun.com> Message-ID: <4A0B397F.9000403@Sun.COM> [just to you, not that it matters for the outcome of the voting, but you missed at least the names of John Cuthbertson and Poonam Bajaj who are also, i believe, members of the HotSpot group.] -- ramki On 05/13/09 14:04, Erik Trimble wrote: > Question: Should the Hotspot Group sponsor the proposed Hotspot Express > [1] Project? > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC a week from Friday, > the 22nd of May. As an optimization, if an absolute majority of the > Group's Members votes one way or the other prior to that time then > the decision may be rendered earlier. > > Only Members of the Hotspot Group are eligible to vote on this > decision. The current Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Laurent Daynes > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > Once a decision has been made the votes will be summarized and > reported to this list and also to discuss at openjdk.java.net. > > > > [1] See: > http://mail.openjdk.java.net/pipermail/announce/2009-May/000076.html > From Y.S.Ramakrishna at Sun.COM Wed May 13 14:20:29 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Wed, 13 May 2009 14:20:29 -0700 Subject: CFV: Project Sponsorship: Hotspot Express In-Reply-To: <4A0B35CF.8050502@sun.com> References: <4A0B35CF.8050502@sun.com> Message-ID: <4A0B399D.2060500@Sun.COM> Vote: yes On 05/13/09 14:04, Erik Trimble wrote: > Question: Should the Hotspot Group sponsor the proposed Hotspot Express > [1] Project? > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC a week from Friday, > the 22nd of May. As an optimization, if an absolute majority of the > Group's Members votes one way or the other prior to that time then > the decision may be rendered earlier. > > Only Members of the Hotspot Group are eligible to vote on this > decision. The current Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Laurent Daynes > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > Once a decision has been made the votes will be summarized and > reported to this list and also to discuss at openjdk.java.net. > > > > [1] See: > http://mail.openjdk.java.net/pipermail/announce/2009-May/000076.html > From Chris.Phillips at Sun.COM Wed May 13 14:20:28 2009 From: Chris.Phillips at Sun.COM (Chris Phillips) Date: Wed, 13 May 2009 17:20:28 -0400 Subject: CFV: Project Sponsorship: Hotspot Express In-Reply-To: <4A0B35CF.8050502@sun.com> References: <4A0B35CF.8050502@sun.com> Message-ID: <4A0B399C.4080203@Sun.Com> Vote: yes Erik Trimble wrote: > Question: Should the Hotspot Group sponsor the proposed Hotspot Express > [1] Project? > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC a week from Friday, > the 22nd of May. As an optimization, if an absolute majority of the > Group's Members votes one way or the other prior to that time then > the decision may be rendered earlier. > > Only Members of the Hotspot Group are eligible to vote on this > decision. The current Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Laurent Daynes > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > Once a decision has been made the votes will be summarized and > reported to this list and also to discuss at openjdk.java.net. > > > > [1] See: > http://mail.openjdk.java.net/pipermail/announce/2009-May/000076.html > -- -- -- Woda: "Java: write once, debug anywhere" Hong Zhang http://thehenrys.ca | Chris Phillips - Sun Java Sustaining JVM Engineer, | | mailto:Chris.Phillips at Sun.Com (416)483-3768 | | http://LGonQn.Org/www/Chris.Phillips cell: (416)505-3610 | "EPIC stands for Expects Perfectly Intuitive Compilers" P. Bannon http://www.hazmatmodine.com NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. "blah blah blah - Ginger!" -- From Karen.Kinnear at Sun.COM Wed May 13 14:21:01 2009 From: Karen.Kinnear at Sun.COM (Karen Kinnear) Date: Wed, 13 May 2009 17:21:01 -0400 Subject: CFV: Project Sponsorship: Hotspot Express In-Reply-To: <4A0B35CF.8050502@sun.com> References: <4A0B35CF.8050502@sun.com> Message-ID: Vote: yes On May 13, 2009, at 5:04 PM, Erik Trimble wrote: > Question: Should the Hotspot Group sponsor the proposed Hotspot > Express [1] Project? > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC a week from > Friday, > the 22nd of May. As an optimization, if an absolute majority of the > Group's Members votes one way or the other prior to that time then > the decision may be rendered earlier. > > Only Members of the Hotspot Group are eligible to vote on this > decision. The current Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Laurent Daynes > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > Once a decision has been made the votes will be summarized and > reported to this list and also to discuss at openjdk.java.net. > > > > [1] See: http://mail.openjdk.java.net/pipermail/announce/2009-May/000076.html > > -- > Erik Trimble > Java System Support > Mailstop: usca22-123 > Phone: x17195 > Santa Clara, CA > Timezone: US/Pacific (GMT-0800) > From John.Coomes at sun.com Wed May 13 14:37:47 2009 From: John.Coomes at sun.com (John Coomes) Date: Wed, 13 May 2009 14:37:47 -0700 Subject: CFV: Project Sponsorship: Hotspot Express In-Reply-To: <4A0B35CF.8050502@sun.com> References: <4A0B35CF.8050502@sun.com> Message-ID: <18955.15787.402034.685341@sun.com> Vote: yes Erik Trimble (Erik.Trimble at Sun.COM) wrote: > Question: Should the Hotspot Group sponsor the proposed Hotspot Express [1] Project? > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC a week from Friday, > the 22nd of May. As an optimization, if an absolute majority of the > Group's Members votes one way or the other prior to that time then > the decision may be rendered earlier. > > Only Members of the Hotspot Group are eligible to vote on this > decision. The current Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Laurent Daynes > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > Once a decision has been made the votes will be summarized and > reported to this list and also to discuss at openjdk.java.net. > > > [1] See: http://mail.openjdk.java.net/pipermail/announce/2009-May/000076.html > > -- > Erik Trimble > Java System Support > Mailstop: usca22-123 > Phone: x17195 > Santa Clara, CA > Timezone: US/Pacific (GMT-0800) > From Thomas.Rodriguez at Sun.COM Wed May 13 14:47:03 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 13 May 2009 14:47:03 -0700 Subject: CFV: Project Sponsorship: Hotspot Express In-Reply-To: <4A0B35CF.8050502@sun.com> References: <4A0B35CF.8050502@sun.com> Message-ID: Vote: yes On May 13, 2009, at 2:04 PM, Erik Trimble wrote: > Question: Should the Hotspot Group sponsor the proposed Hotspot > Express [1] Project? > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC a week from > Friday, > the 22nd of May. As an optimization, if an absolute majority of the > Group's Members votes one way or the other prior to that time then > the decision may be rendered earlier. > > Only Members of the Hotspot Group are eligible to vote on this > decision. The current Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Laurent Daynes > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > Once a decision has been made the votes will be summarized and > reported to this list and also to discuss at openjdk.java.net. > > > > [1] See: http://mail.openjdk.java.net/pipermail/announce/2009-May/000076.html > > -- > Erik Trimble > Java System Support > Mailstop: usca22-123 > Phone: x17195 > Santa Clara, CA > Timezone: US/Pacific (GMT-0800) > From Erik.Trimble at Sun.COM Wed May 13 14:58:43 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Wed, 13 May 2009 14:58:43 -0700 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <20090513205910.247D95CE0@eggemoggin.niobe.net> References: <20090513205910.247D95CE0@eggemoggin.niobe.net> Message-ID: <4A0B4293.8060800@sun.com> Mark Reinhold wrote: >> Date: Wed, 13 May 2009 09:44:22 +0200 >> From: Mark Wielaard >> > > >> On Wed, 2009-05-06 at 08:09 -0700, Mark Reinhold wrote: >> >>> In order to move this forward, I'll go ahead and create the proposed >>> forests on hg.openjdk.java.net. >>> >> Thanks, how are they called and are they already populated? >> > > http://hg.openjdk.java.net/hsx/hsx14/baseline > http://hg.openjdk.java.net/hsx/hsx14/master > > (I don't know why the tip changeset in each of these repos is labeled > "6836332: Bump Hotspot 14 build number to 15", which seems odd.) > > Because it's a bump in the BUILD number, not the VERSION number. I.e. Hotspot Express 14 build 15. java -version should thus report '14.0 b15' Also, we're not tagging anymore. That's a completely different discussion. :-) >>> In the fullness of time I still think there's value in having a HotSpot >>> Express Project. Those of us who've been involved in this discussion >>> will understand what's going on, but it'd be good to have an obvious >>> place where people new to the topic can find documentation. >>> >> There was a vote started to create a separate express project, but then >> aborted because of procedural issues (wrong mailinglist). It is unclear >> whether or not the project creation is stuck now. >> > > Not aborted, just delayed. Dalibor is assisting. > > - Mark > The vote is on-going. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From Peter.Kessler at Sun.COM Wed May 13 15:17:27 2009 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Wed, 13 May 2009 15:17:27 -0700 Subject: CFV: Project Sponsorship: Hotspot Express In-Reply-To: <4A0B35CF.8050502@sun.com> References: <4A0B35CF.8050502@sun.com> Message-ID: <4A0B46F7.1090407@Sun.COM> Vote: yes ... peter Erik Trimble wrote: > Question: Should the Hotspot Group sponsor the proposed Hotspot Express > [1] Project? > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC a week from Friday, > the 22nd of May. As an optimization, if an absolute majority of the > Group's Members votes one way or the other prior to that time then > the decision may be rendered earlier. > > Only Members of the Hotspot Group are eligible to vote on this > decision. The current Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Laurent Daynes > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > Once a decision has been made the votes will be summarized and > reported to this list and also to discuss at openjdk.java.net. > > > > [1] See: > http://mail.openjdk.java.net/pipermail/announce/2009-May/000076.html > From David.Holmes at Sun.COM Wed May 13 17:18:55 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Thu, 14 May 2009 10:18:55 +1000 Subject: CFV: Project Sponsorship: Hotspot Express In-Reply-To: <4A0B35CF.8050502@sun.com> References: <4A0B35CF.8050502@sun.com> Message-ID: <4A0B636F.4030007@sun.com> Vote: yes David Erik Trimble said the following on 05/14/09 07:04: > Question: Should the Hotspot Group sponsor the proposed Hotspot Express > [1] Project? > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC a week from Friday, > the 22nd of May. As an optimization, if an absolute majority of the > Group's Members votes one way or the other prior to that time then > the decision may be rendered earlier. > > Only Members of the Hotspot Group are eligible to vote on this > decision. The current Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Laurent Daynes > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > Once a decision has been made the votes will be summarized and > reported to this list and also to discuss at openjdk.java.net. > > > > [1] See: > http://mail.openjdk.java.net/pipermail/announce/2009-May/000076.html > From Paul.Hohensee at Sun.COM Thu May 14 06:55:11 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Thu, 14 May 2009 09:55:11 -0400 Subject: CFV: Project Sponsorship: Hotspot Express In-Reply-To: <4A0B35CF.8050502@sun.com> References: <4A0B35CF.8050502@sun.com> Message-ID: <4A0C22BF.50907@sun.com> Vote: yes Erik Trimble wrote: > Question: Should the Hotspot Group sponsor the proposed Hotspot > Express [1] Project? > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC a week from Friday, > the 22nd of May. As an optimization, if an absolute majority of the > Group's Members votes one way or the other prior to that time then > the decision may be rendered earlier. > > Only Members of the Hotspot Group are eligible to vote on this > decision. The current Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Laurent Daynes > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > Once a decision has been made the votes will be summarized and > reported to this list and also to discuss at openjdk.java.net. > > > > [1] See: > http://mail.openjdk.java.net/pipermail/announce/2009-May/000076.html > From john.coomes at sun.com Thu May 14 20:35:51 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 15 May 2009 03:35:51 +0000 Subject: hg: jdk7/hotspot: 2 new changesets Message-ID: <20090515033551.EF1B3EE9F@hg.openjdk.java.net> Changeset: 030142474602 Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/030142474602 Added tag jdk7-b58 for changeset 59b497130f82 ! .hgtags Changeset: 0d76c4da605f Author: vasya Date: 2009-05-14 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/0d76c4da605f Added tag jdk7-b59 for changeset 030142474602 ! .hgtags From john.coomes at sun.com Thu May 14 20:40:13 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 15 May 2009 03:40:13 +0000 Subject: hg: jdk7/hotspot/corba: 4 new changesets Message-ID: <20090515034017.A621CEEA4@hg.openjdk.java.net> Changeset: e149090eb21a Author: tbell Date: 2009-05-04 18:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/e149090eb21a 6529590: flaw in com.sun.corba.se.impl.presentation.rmi.IDLNameTranslatorImpl Reviewed-by: darcy ! make/com/sun/corba/se/sources/Makefile ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl.java ! src/share/classes/com/sun/tools/corba/se/idl/first.set ! src/share/classes/com/sun/tools/corba/se/idl/follow.set ! src/share/classes/com/sun/tools/corba/se/idl/grammar.idl ! src/share/classes/com/sun/tools/corba/se/idl/grammar3.idl ! src/share/classes/com/sun/tools/corba/se/idl/idl.prp ! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp Changeset: 2e3b8edab3ef Author: tbell Date: 2009-05-04 22:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/2e3b8edab3ef Merge Changeset: 7e6b2b55c00c Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/7e6b2b55c00c Added tag jdk7-b58 for changeset 2e3b8edab3ef ! .hgtags Changeset: e9ba2b962ddf Author: vasya Date: 2009-05-14 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/e9ba2b962ddf Added tag jdk7-b59 for changeset 7e6b2b55c00c ! .hgtags From john.coomes at sun.com Thu May 14 20:48:21 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 15 May 2009 03:48:21 +0000 Subject: hg: jdk7/hotspot/jaxp: 4 new changesets Message-ID: <20090515034828.A2E65EEA9@hg.openjdk.java.net> Changeset: 3abf80631f99 Author: tbell Date: 2009-05-04 21:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/3abf80631f99 6588002: XSLTProcessorApplet still allows reading from forbidden URLs Reviewed-by: darcy - src/share/classes/com/sun/org/apache/xalan/internal/client/XSLTProcessorApplet.java - src/share/classes/com/sun/org/apache/xalan/internal/client/package.html Changeset: 13bf67d8c634 Author: tbell Date: 2009-05-04 22:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/13bf67d8c634 Merge - src/share/classes/com/sun/org/apache/xalan/internal/client/XSLTProcessorApplet.java - src/share/classes/com/sun/org/apache/xalan/internal/client/package.html Changeset: 75113d7ce083 Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/75113d7ce083 Added tag jdk7-b58 for changeset 13bf67d8c634 ! .hgtags Changeset: 748976d69503 Author: vasya Date: 2009-05-14 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/748976d69503 Added tag jdk7-b59 for changeset 75113d7ce083 ! .hgtags From john.coomes at sun.com Thu May 14 20:52:26 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 15 May 2009 03:52:26 +0000 Subject: hg: jdk7/hotspot/jaxws: 4 new changesets Message-ID: <20090515035231.D0989EEAE@hg.openjdk.java.net> Changeset: 42dfec6871f6 Author: tbell Date: 2009-05-04 21:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/42dfec6871f6 6658158: Mutable statics in SAAJ (findbugs) 6658163: txw2.DatatypeWriter.BUILDIN is a mutable static (findbugs) Reviewed-by: darcy ! src/share/classes/com/sun/codemodel/internal/JClassContainer.java ! src/share/classes/com/sun/codemodel/internal/JDefinedClass.java ! src/share/classes/com/sun/codemodel/internal/JForEach.java ! src/share/classes/com/sun/codemodel/internal/JMethod.java ! src/share/classes/com/sun/codemodel/internal/JMods.java ! src/share/classes/com/sun/codemodel/internal/util/SingleByteEncoder.java ! src/share/classes/com/sun/codemodel/internal/util/Surrogate.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnection.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/AttachmentPartImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/EnvelopeFactory.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ImageDataContentHandler.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageFactoryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SAAJMetaFactoryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPFactoryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPPartImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/CDATAImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/CommentImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/TextImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/name/NameImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Fault1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Header1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/HeaderElement1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Message1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPPart1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Body1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Detail1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Envelope1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Fault1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Header1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/HeaderElement1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPPart1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/RejectDoctypeSaxFilter.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/transform/EfficientStreamingTransformer.java ! src/share/classes/com/sun/xml/internal/txw2/DatatypeWriter.java ! src/share/classes/com/sun/xml/internal/txw2/Document.java Changeset: 5fb4fbea81c3 Author: tbell Date: 2009-05-04 22:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/5fb4fbea81c3 Merge Changeset: f64566bf4c2b Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/f64566bf4c2b Added tag jdk7-b58 for changeset 5fb4fbea81c3 ! .hgtags Changeset: 4fa7398559d0 Author: vasya Date: 2009-05-14 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/4fa7398559d0 Added tag jdk7-b59 for changeset f64566bf4c2b ! .hgtags From john.coomes at sun.com Thu May 14 20:57:41 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 15 May 2009 03:57:41 +0000 Subject: hg: jdk7/hotspot/jdk: 27 new changesets Message-ID: <20090515040326.1B14BEEB3@hg.openjdk.java.net> Changeset: b056c42ea5b4 Author: tbell Date: 2009-05-04 18:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b056c42ea5b4 6837214: Update JDK7 man pages Reviewed-by: darcy, bpatel, tbell Contributed-by: jacob.royal at sun.com ! src/linux/doc/man/appletviewer.1 ! src/linux/doc/man/apt.1 ! src/linux/doc/man/extcheck.1 ! src/linux/doc/man/idlj.1 ! src/linux/doc/man/ja/appletviewer.1 ! src/linux/doc/man/ja/apt.1 ! src/linux/doc/man/ja/extcheck.1 ! src/linux/doc/man/ja/idlj.1 ! src/linux/doc/man/ja/jar.1 ! src/linux/doc/man/ja/jarsigner.1 ! src/linux/doc/man/ja/java.1 ! src/linux/doc/man/ja/javac.1 ! src/linux/doc/man/ja/javadoc.1 ! src/linux/doc/man/ja/javah.1 ! src/linux/doc/man/ja/javap.1 ! src/linux/doc/man/ja/javaws.1 ! src/linux/doc/man/ja/jconsole.1 ! src/linux/doc/man/ja/jdb.1 ! src/linux/doc/man/ja/jhat.1 ! src/linux/doc/man/ja/jinfo.1 ! src/linux/doc/man/ja/jmap.1 ! src/linux/doc/man/ja/jps.1 ! src/linux/doc/man/ja/jrunscript.1 ! src/linux/doc/man/ja/jsadebugd.1 ! src/linux/doc/man/ja/jstack.1 ! src/linux/doc/man/ja/jstat.1 ! src/linux/doc/man/ja/jstatd.1 ! src/linux/doc/man/ja/keytool.1 ! src/linux/doc/man/ja/native2ascii.1 ! src/linux/doc/man/ja/orbd.1 ! src/linux/doc/man/ja/pack200.1 ! src/linux/doc/man/ja/policytool.1 ! src/linux/doc/man/ja/rmic.1 ! src/linux/doc/man/ja/rmid.1 ! src/linux/doc/man/ja/rmiregistry.1 ! src/linux/doc/man/ja/schemagen.1 ! src/linux/doc/man/ja/serialver.1 ! src/linux/doc/man/ja/servertool.1 ! src/linux/doc/man/ja/tnameserv.1 ! src/linux/doc/man/ja/unpack200.1 ! src/linux/doc/man/ja/wsgen.1 ! src/linux/doc/man/ja/wsimport.1 ! src/linux/doc/man/ja/xjc.1 ! src/linux/doc/man/jar.1 ! src/linux/doc/man/jarsigner.1 ! src/linux/doc/man/java.1 ! src/linux/doc/man/javac.1 ! src/linux/doc/man/javadoc.1 ! src/linux/doc/man/javah.1 ! src/linux/doc/man/javap.1 ! src/linux/doc/man/javaws.1 ! src/linux/doc/man/jconsole.1 ! src/linux/doc/man/jdb.1 ! src/linux/doc/man/jhat.1 ! src/linux/doc/man/jinfo.1 ! src/linux/doc/man/jmap.1 ! src/linux/doc/man/jps.1 ! src/linux/doc/man/jrunscript.1 ! src/linux/doc/man/jsadebugd.1 ! src/linux/doc/man/jstack.1 ! src/linux/doc/man/jstat.1 ! src/linux/doc/man/jstatd.1 ! src/linux/doc/man/keytool.1 ! src/linux/doc/man/native2ascii.1 ! src/linux/doc/man/orbd.1 ! src/linux/doc/man/pack200.1 ! src/linux/doc/man/policytool.1 ! src/linux/doc/man/rmic.1 ! src/linux/doc/man/rmid.1 ! src/linux/doc/man/rmiregistry.1 ! src/linux/doc/man/schemagen.1 ! src/linux/doc/man/serialver.1 ! src/linux/doc/man/servertool.1 ! src/linux/doc/man/tnameserv.1 ! src/linux/doc/man/unpack200.1 ! src/linux/doc/man/wsgen.1 ! src/linux/doc/man/wsimport.1 ! src/linux/doc/man/xjc.1 ! src/solaris/doc/sun/man/man1/appletviewer.1 ! src/solaris/doc/sun/man/man1/apt.1 ! src/solaris/doc/sun/man/man1/extcheck.1 ! src/solaris/doc/sun/man/man1/idlj.1 ! src/solaris/doc/sun/man/man1/ja/appletviewer.1 ! src/solaris/doc/sun/man/man1/ja/apt.1 ! src/solaris/doc/sun/man/man1/ja/extcheck.1 ! src/solaris/doc/sun/man/man1/ja/idlj.1 ! src/solaris/doc/sun/man/man1/ja/jar.1 ! src/solaris/doc/sun/man/man1/ja/jarsigner.1 ! src/solaris/doc/sun/man/man1/ja/java.1 ! src/solaris/doc/sun/man/man1/ja/javac.1 ! src/solaris/doc/sun/man/man1/ja/javadoc.1 ! src/solaris/doc/sun/man/man1/ja/javah.1 ! src/solaris/doc/sun/man/man1/ja/javap.1 ! src/solaris/doc/sun/man/man1/ja/javaws.1 ! src/solaris/doc/sun/man/man1/ja/jconsole.1 ! src/solaris/doc/sun/man/man1/ja/jdb.1 ! src/solaris/doc/sun/man/man1/ja/jhat.1 ! src/solaris/doc/sun/man/man1/ja/jinfo.1 ! src/solaris/doc/sun/man/man1/ja/jmap.1 ! src/solaris/doc/sun/man/man1/ja/jps.1 ! src/solaris/doc/sun/man/man1/ja/jrunscript.1 ! src/solaris/doc/sun/man/man1/ja/jsadebugd.1 ! src/solaris/doc/sun/man/man1/ja/jstack.1 ! src/solaris/doc/sun/man/man1/ja/jstat.1 ! src/solaris/doc/sun/man/man1/ja/jstatd.1 ! src/solaris/doc/sun/man/man1/ja/keytool.1 ! src/solaris/doc/sun/man/man1/ja/native2ascii.1 ! src/solaris/doc/sun/man/man1/ja/orbd.1 ! src/solaris/doc/sun/man/man1/ja/pack200.1 ! src/solaris/doc/sun/man/man1/ja/policytool.1 ! src/solaris/doc/sun/man/man1/ja/rmic.1 ! src/solaris/doc/sun/man/man1/ja/rmid.1 ! src/solaris/doc/sun/man/man1/ja/rmiregistry.1 ! src/solaris/doc/sun/man/man1/ja/schemagen.1 ! src/solaris/doc/sun/man/man1/ja/serialver.1 ! src/solaris/doc/sun/man/man1/ja/servertool.1 ! src/solaris/doc/sun/man/man1/ja/tnameserv.1 ! src/solaris/doc/sun/man/man1/ja/unpack200.1 ! src/solaris/doc/sun/man/man1/ja/wsgen.1 ! src/solaris/doc/sun/man/man1/ja/wsimport.1 ! src/solaris/doc/sun/man/man1/ja/xjc.1 ! src/solaris/doc/sun/man/man1/jar.1 ! src/solaris/doc/sun/man/man1/jarsigner.1 ! src/solaris/doc/sun/man/man1/java.1 ! src/solaris/doc/sun/man/man1/javac.1 ! src/solaris/doc/sun/man/man1/javadoc.1 ! src/solaris/doc/sun/man/man1/javah.1 ! src/solaris/doc/sun/man/man1/javap.1 ! src/solaris/doc/sun/man/man1/javaws.1 ! src/solaris/doc/sun/man/man1/jconsole.1 ! src/solaris/doc/sun/man/man1/jdb.1 ! src/solaris/doc/sun/man/man1/jhat.1 ! src/solaris/doc/sun/man/man1/jinfo.1 ! src/solaris/doc/sun/man/man1/jmap.1 ! src/solaris/doc/sun/man/man1/jps.1 ! src/solaris/doc/sun/man/man1/jrunscript.1 ! src/solaris/doc/sun/man/man1/jsadebugd.1 ! src/solaris/doc/sun/man/man1/jstack.1 ! src/solaris/doc/sun/man/man1/jstat.1 ! src/solaris/doc/sun/man/man1/jstatd.1 ! src/solaris/doc/sun/man/man1/keytool.1 ! src/solaris/doc/sun/man/man1/native2ascii.1 ! src/solaris/doc/sun/man/man1/orbd.1 ! src/solaris/doc/sun/man/man1/pack200.1 ! src/solaris/doc/sun/man/man1/policytool.1 ! src/solaris/doc/sun/man/man1/rmic.1 ! src/solaris/doc/sun/man/man1/rmid.1 ! src/solaris/doc/sun/man/man1/rmiregistry.1 ! src/solaris/doc/sun/man/man1/schemagen.1 ! src/solaris/doc/sun/man/man1/serialver.1 ! src/solaris/doc/sun/man/man1/servertool.1 ! src/solaris/doc/sun/man/man1/tnameserv.1 ! src/solaris/doc/sun/man/man1/unpack200.1 ! src/solaris/doc/sun/man/man1/wsgen.1 ! src/solaris/doc/sun/man/man1/wsimport.1 ! src/solaris/doc/sun/man/man1/xjc.1 Changeset: a33222e53611 Author: prr Date: 2009-04-02 10:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a33222e53611 6753173: No need to read all the TrueType 'post' table to get underline info Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/TrueTypeFont.java Changeset: e3b4eb55a696 Author: lana Date: 2009-04-08 15:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e3b4eb55a696 Merge - make/common/shared/Compiler.gmk - make/jprt.config - src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java Changeset: e61d93fc8ed1 Author: mchung Date: 2009-04-14 17:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e61d93fc8ed1 6818072: Load Ductus using Class.forName if exist instead of using the service loader Summary: First attempt Class.forName to load Ductus class before using service loader Reviewed-by: flar, prr ! src/share/classes/sun/java2d/pipe/RenderingEngine.java Changeset: d609ae2faac2 Author: jgodinez Date: 2009-04-15 08:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d609ae2faac2 6827989: Use Unsafe.copyMemory for array->Unsafe copy operations in RenderBuffer Reviewed-by: campbell, flar Contributed-by: linuxhippy ! make/sun/awt/FILES_c_unix.gmk ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-linux ! src/share/classes/sun/java2d/pipe/RenderBuffer.java - src/share/native/sun/java2d/pipe/RenderBuffer.c Changeset: c3aaa11e4eb6 Author: jgodinez Date: 2009-04-20 12:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c3aaa11e4eb6 6821495: test/java/awt/print/PrinterJob/PrtException.java fails Reviewed-by: igor, prr ! test/java/awt/PrintJob/EdgeTest/EdgeTest.java ! test/java/awt/PrintJob/MultipleEnd/MultipleEnd.java + test/java/awt/print/PrinterJob/Collate2DPrintingTest.java + test/java/awt/print/PrinterJob/PrtException.java ! test/javax/print/CheckDupFlavor.java + test/javax/print/LookupServices.java ! test/javax/print/TestRaceCond.java + test/javax/print/attribute/Chroma.java + test/javax/print/attribute/ChromaticityValues.java + test/javax/print/attribute/GetCopiesSupported.java ! test/javax/print/attribute/PSCopiesFlavorTest.java + test/javax/print/attribute/SidesPageRangesTest.java + test/javax/print/attribute/SupportedPrintableAreas.java + test/javax/print/attribute/autosense/PrintAutoSenseData.java Changeset: 53ca5822bdfe Author: jgodinez Date: 2009-04-21 09:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/53ca5822bdfe 6829678: StrokeShapeTest: createStrokedShape() behaves differently Reviewed-by: igor, flar Contributed-by: rkennke ! src/share/classes/sun/java2d/pisces/Stroker.java + test/sun/pisces/StrokeShapeTest.java Changeset: b4450e6de8a3 Author: jgodinez Date: 2009-04-28 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b4450e6de8a3 Merge ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/mapfile-vers-linux ! src/share/classes/sun/font/TrueTypeFont.java - src/share/classes/sun/text/normalizer/UProperty.java - src/share/native/java/util/zip/ZipEntry.c - src/windows/native/sun/windows/awt_KeyboardFocusManager.h Changeset: 662a327cfe1d Author: jgodinez Date: 2009-04-29 12:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/662a327cfe1d Merge - src/share/native/sun/java2d/pipe/RenderBuffer.c Changeset: f8b061ea131c Author: jgodinez Date: 2009-05-05 09:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f8b061ea131c Merge - src/share/native/sun/java2d/pipe/RenderBuffer.c Changeset: 057e4afcf978 Author: alanb Date: 2009-04-23 19:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/057e4afcf978 6832557: TEST_BUG: java/lang/Class/getEnclosingConstructor/EnclosingConstructorTests.java fails to compile Reviewed-by: darcy, mcimadamore ! test/java/lang/Class/getEnclosingConstructor/EnclosingConstructorTests.java Changeset: 164ce9ff8b58 Author: mchung Date: 2009-04-27 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/164ce9ff8b58 6829503: addShutdownHook fails if called after shutdown has commenced. Summary: allow shutdown hook to be added during shutdown and handle properly if it fails to add Reviewed-by: alanb, dholmes, martin ! src/share/classes/java/io/Console.java ! src/share/classes/java/io/DeleteOnExitHook.java ! src/share/classes/java/lang/ApplicationShutdownHooks.java ! src/share/classes/java/lang/Shutdown.java ! src/share/classes/java/lang/System.java ! src/share/classes/sun/misc/JavaLangAccess.java + test/java/lang/Runtime/shutdown/ShutdownHooks.java + test/java/lang/Runtime/shutdown/ShutdownHooks.sh Changeset: d2114c1adb2d Author: sherman Date: 2009-05-01 12:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d2114c1adb2d 6836489: Incorrect @link usage in java.util.zip API doc Summary: correct the wrong @link tag Reviewed-by: alanb ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/java/util/zip/ZipInputStream.java ! src/share/classes/java/util/zip/ZipOutputStream.java Changeset: e1a713f0361f Author: alanb Date: 2009-05-04 19:25 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e1a713f0361f 6834246: (ch) AsynchronousSocketChannel#write completes with wrong number of bytes written under load (win) Reviewed-by: sherman ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! src/windows/native/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.c + test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java Changeset: b3720710a4ba Author: tbell Date: 2009-05-04 22:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b3720710a4ba Merge Changeset: d201987cb76c Author: jrose Date: 2009-05-05 22:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d201987cb76c 6829144: JSR 292 JVM features need a provisional Java API Summary: JDK API and runtime (partial) for anonk, meth, indy Reviewed-by: mr ! make/docs/CORE_PKGS.gmk ! make/java/Makefile + make/java/dyn/Makefile + src/share/classes/java/dyn/CallSite.java + src/share/classes/java/dyn/InvokeDynamic.java + src/share/classes/java/dyn/InvokeDynamicBootstrapError.java + src/share/classes/java/dyn/JavaMethodHandle.java + src/share/classes/java/dyn/Linkage.java + src/share/classes/java/dyn/LinkagePermission.java + src/share/classes/java/dyn/MethodHandle.java + src/share/classes/java/dyn/MethodHandles.java + src/share/classes/java/dyn/MethodType.java + src/share/classes/java/dyn/MethodTypeForm.java + src/share/classes/java/dyn/NoAccessException.java + src/share/classes/java/dyn/WrongMethodTypeException.java + src/share/classes/java/dyn/package-info.java + src/share/classes/sun/dyn/Access.java + src/share/classes/sun/dyn/AdapterMethodHandle.java + src/share/classes/sun/dyn/BoundMethodHandle.java + src/share/classes/sun/dyn/CallSiteImpl.java + src/share/classes/sun/dyn/DirectMethodHandle.java + src/share/classes/sun/dyn/FilterGeneric.java + src/share/classes/sun/dyn/FilterOneArgument.java + src/share/classes/sun/dyn/FromGeneric.java + src/share/classes/sun/dyn/Invokers.java + src/share/classes/sun/dyn/MemberName.java + src/share/classes/sun/dyn/MethodHandleImpl.java + src/share/classes/sun/dyn/MethodHandleNatives.java + src/share/classes/sun/dyn/MethodTypeImpl.java + src/share/classes/sun/dyn/ToGeneric.java + src/share/classes/sun/dyn/anon/AnonymousClassLoader.java + src/share/classes/sun/dyn/anon/ConstantPoolParser.java + src/share/classes/sun/dyn/anon/ConstantPoolPatch.java + src/share/classes/sun/dyn/anon/ConstantPoolVisitor.java + src/share/classes/sun/dyn/anon/InvalidConstantPoolFormatException.java + src/share/classes/sun/dyn/empty/Empty.java + src/share/classes/sun/dyn/package-info.java + src/share/classes/sun/dyn/util/BytecodeName.java + src/share/classes/sun/dyn/util/BytecodeSignature.java + src/share/classes/sun/dyn/util/ValueConversions.java + src/share/classes/sun/dyn/util/VerifyAccess.java + src/share/classes/sun/dyn/util/VerifyType.java + src/share/classes/sun/dyn/util/Wrapper.java + src/share/classes/sun/dyn/util/package-info.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/javavm/export/classfile_constants.h ! src/share/native/common/check_code.c ! src/share/native/common/opcodes.in_out Changeset: 9ba256e2e5c1 Author: tbell Date: 2009-05-05 23:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9ba256e2e5c1 Merge Changeset: 878863c9072d Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/878863c9072d Added tag jdk7-b58 for changeset 9ba256e2e5c1 ! .hgtags Changeset: 2007e3d9c195 Author: anthony Date: 2009-05-05 14:45 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2007e3d9c195 6762511: Translucency is not working on Linux using Metacity Summary: Introduced additional blits and new X11 surface types (ARGB, ABGR) Reviewed-by: art, avu ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitLoops.java ! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java ! src/solaris/native/sun/awt/X11Color.c ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_p.h Changeset: ba95c9101e50 Author: art Date: 2009-05-06 12:39 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ba95c9101e50 6837004: java.awt.GraphicsDevice.setFullScreenWindow throws NPE for windows with background color not set Reviewed-by: yan, dcherepanov ! src/share/classes/java/awt/GraphicsDevice.java + test/java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java Changeset: b28b073e72b6 Author: anthony Date: 2009-05-06 20:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b28b073e72b6 6838046: Rollback 6762511 due to build failure (6838003) Reviewed-by: yan ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitLoops.java ! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java ! src/solaris/native/sun/awt/X11Color.c ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_p.h Changeset: 2b86dbc51d11 Author: yan Date: 2009-05-06 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2b86dbc51d11 Merge Changeset: 0c6f5f1c58fd Author: yan Date: 2009-05-12 00:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0c6f5f1c58fd Merge Changeset: 2387e3b1994e Author: jrose Date: 2009-05-11 21:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2387e3b1994e 6839802: java.dyn needs to be on the CORE_PKGS list Summary: fix makefile to expose the new APIs in the core list; edit some javadocs for correctness Reviewed-by: mr ! make/common/Release.gmk ! make/docs/CORE_PKGS.gmk ! src/share/classes/java/dyn/CallSite.java ! src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/dyn/Linkage.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/MethodType.java Changeset: 29180ef374c8 Author: jrose Date: 2009-05-12 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/29180ef374c8 6839839: access checking logic is wrong at three points in MethodHandles Summary: point fixes to access checking logic Reviewed-by: mr ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/sun/dyn/DirectMethodHandle.java ! src/share/classes/sun/dyn/MemberName.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/MethodHandleNatives.java ! src/share/classes/sun/dyn/util/VerifyAccess.java Changeset: 2a5a1b269e89 Author: xdono Date: 2009-05-12 14:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2a5a1b269e89 Merge Changeset: 827a93c4d06a Author: vasya Date: 2009-05-14 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/827a93c4d06a Added tag jdk7-b59 for changeset 2a5a1b269e89 ! .hgtags From john.coomes at sun.com Thu May 14 21:18:13 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 15 May 2009 04:18:13 +0000 Subject: hg: jdk7/hotspot/langtools: 4 new changesets Message-ID: <20090515041821.D3A94EEB8@hg.openjdk.java.net> Changeset: e2722bd43f3a Author: jrose Date: 2009-05-04 21:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e2722bd43f3a 6829189: Java programming with JSR 292 needs language support Summary: Language changes documented in http://wikis.sun.com/display/mlvm/ProjectCoinProposal Reviewed-by: jjg, darcy, mcimadamore ! src/share/classes/com/sun/tools/classfile/Opcode.java ! src/share/classes/com/sun/tools/javac/code/Symtab.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/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ByteCodes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java ! src/share/classes/sun/tools/javap/JavapPrinter.java ! src/share/classes/sun/tools/javap/RuntimeConstants.java + test/tools/javac/meth/InvokeDyn.java + test/tools/javac/meth/InvokeMH.java + test/tools/javac/meth/MakeNegTests.sh + test/tools/javac/quid/MakeNegTests.sh + test/tools/javac/quid/QuotedIdent.java + test/tools/javac/quid/QuotedIdent2.java Changeset: 5bcac54d408b Author: tbell Date: 2009-05-04 22:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/5bcac54d408b Merge Changeset: 88bcb6772159 Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/88bcb6772159 Added tag jdk7-b58 for changeset 5bcac54d408b ! .hgtags Changeset: 0f653be1a42f Author: vasya Date: 2009-05-14 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/0f653be1a42f Added tag jdk7-b59 for changeset 88bcb6772159 ! .hgtags From John.Rose at Sun.COM Fri May 15 13:20:29 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 15 May 2009 13:20:29 -0700 Subject: CFV: Project Sponsorship: Hotspot Express In-Reply-To: <4A0B35CF.8050502@sun.com> References: <4A0B35CF.8050502@sun.com> Message-ID: <50AC0382-5BC8-4238-BC8F-109097FEBFC7@sun.com> Vote: yes On May 13, 2009, at 2:04 PM, Erik Trimble wrote: > Question: Should the Hotspot Group sponsor the proposed Hotspot > Express [1] Project? From Erik.Trimble at Sun.COM Mon May 18 11:57:18 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Mon, 18 May 2009 11:57:18 -0700 Subject: CFV: Project Sponsorship: Hotspot Express In-Reply-To: <4A0B35CF.8050502@sun.com> References: <4A0B35CF.8050502@sun.com> Message-ID: <1242673038.5188.4.camel@ghostbox.sfbay.sun.com> Vote: Yes On Wed, 2009-05-13 at 14:04 -0700, Erik Trimble wrote: > Question: Should the Hotspot Group sponsor the proposed Hotspot Express [1] Project? > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC a week from Friday, > the 22nd of May. As an optimization, if an absolute majority of the > Group's Members votes one way or the other prior to that time then > the decision may be rendered earlier. > > Only Members of the Hotspot Group are eligible to vote on this > decision. The current Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Laurent Daynes > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > Once a decision has been made the votes will be summarized and > reported to this list and also to discuss at openjdk.java.net. > > > [1] See: http://mail.openjdk.java.net/pipermail/announce/2009-May/000076.html > -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From charles.nutter at sun.com Tue May 19 08:02:44 2009 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Tue, 19 May 2009 10:02:44 -0500 Subject: Tiered compilation? Message-ID: <4A12CA14.40905@sun.com> Hello friends! I'm trying to ascertain the status of the tiered compiler. I recall some statements that it had landed on OpenJDK 7, that it had been merged back into JDK 6, and so on, but I have had trouble finding definitive information. Is tiered compilation available now on any versions of JDK? - Charlie From Christian.Thalinger at Sun.COM Tue May 19 08:17:36 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 19 May 2009 17:17:36 +0200 Subject: Tiered compilation? In-Reply-To: <4A12CA14.40905@sun.com> References: <4A12CA14.40905@sun.com> Message-ID: <1242746256.29179.54.camel@macbook> On Tue, 2009-05-19 at 10:02 -0500, Charles Oliver Nutter wrote: > Hello friends! > > I'm trying to ascertain the status of the tiered compiler. I recall some > statements that it had landed on OpenJDK 7, that it had been merged back > into JDK 6, and so on, but I have had trouble finding definitive > information. > > Is tiered compilation available now on any versions of JDK? AFAIK, no. Igor Veresov is currently working on tiered compilation, but I don't know what the status is and if it's on the top of his TODO list. -- Christian From gbenson at redhat.com Tue May 19 08:33:15 2009 From: gbenson at redhat.com (Gary Benson) Date: Tue, 19 May 2009 16:33:15 +0100 Subject: Tiered compilation? In-Reply-To: <1242746256.29179.54.camel@macbook> References: <4A12CA14.40905@sun.com> <1242746256.29179.54.camel@macbook> Message-ID: <20090519153314.GH3155@redhat.com> Christian Thalinger wrote: > On Tue, 2009-05-19 at 10:02 -0500, Charles Oliver Nutter wrote: > > I'm trying to ascertain the status of the tiered compiler. I > > recall some statements that it had landed on OpenJDK 7, that it > > had been merged back into JDK 6, and so on, but I have had trouble > > finding definitive information. > > > > Is tiered compilation available now on any versions of JDK? > > AFAIK, no. Igor Veresov is currently working on tiered compilation, > but I don't know what the status is and if it's on the top of his > TODO list. ISTR someone on one of the open conference calls saying that tiered compilation was now very much on the back burner. Cheers, Gary -- http://gbenson.net/ From charles.nutter at sun.com Tue May 19 08:44:47 2009 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Tue, 19 May 2009 10:44:47 -0500 Subject: Tiered compilation? In-Reply-To: <20090519153314.GH3155@redhat.com> References: <4A12CA14.40905@sun.com> <1242746256.29179.54.camel@macbook> <20090519153314.GH3155@redhat.com> Message-ID: <4A12D3EF.9090401@sun.com> Gary Benson wrote: > Christian Thalinger wrote: >> AFAIK, no. Igor Veresov is currently working on tiered compilation, >> but I don't know what the status is and if it's on the top of his >> TODO list. > > ISTR someone on one of the open conference calls saying that tiered > compilation was now very much on the back burner. That is unfortunate :( For heavy command-line environments like JRuby it held a lot of hope for reasonably fast startup with no perf impact. I hope something will happen to bring it forward again. - Charlie From yamauchi at google.com Tue May 19 21:32:48 2009 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Tue, 19 May 2009 21:32:48 -0700 Subject: Linux fastdebug build with debug info Message-ID: Hi, If I build a fastdebug VM on Linux (based on openjdk6 b11), the libjvm.so does not get the debug info (symbols and line numbers used mainly in gdb). If I copy'n'paste the following lines from jvmg.make to fastdebug.make (under hotspot/build/linux/makefiles), I get the debug info. # The following lines were copied from jvmg.make # Compiler specific DEBUG_CFLAGS are passed in from gcc.make, sparcWorks.make DEBUG_CFLAGS/DEFAULT= $(DEBUG_CFLAGS) DEBUG_CFLAGS/BYFILE = $(DEBUG_CFLAGS/$@)$(DEBUG_CFLAGS/DEFAULT$(DEBUG_CFLAGS/$@) ) CFLAGS += $(DEBUG_CFLAGS/BYFILE) Is this valid? Is there any historic reason why -g isn't used in the fastdebug build on Linux (such as conflict between -O and -g)? I think the fastdebug should have -g by definition. Thanks, Hiroshi From David.Holmes at Sun.COM Wed May 20 00:00:17 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Wed, 20 May 2009 17:00:17 +1000 Subject: Linux fastdebug build with debug info In-Reply-To: References: Message-ID: <4A13AA81.3060605@sun.com> Hi Hiroshi, The flags are set in gcc.make and should then be picked up by each .make file. But in this case it appears that the linux fastdebug.make is missing the instructions to do that! Looks like a bug to me! Regarding use of -g, hence the settings and comments from gcc.make: # Use the stabs format for debugging information (this is the default # on gcc-2.91). It's good enough, has all the information about line # numbers and local variables, and libjvm_g.so is only about 16M. # Change this back to "-g" if you want the most expressive format. # (warning: that could easily inflate libjvm_g.so to 150M!) # Note: The Itanium gcc compiler crashes when using -gstabs. DEBUG_CFLAGS/ia64 = -g DEBUG_CFLAGS/amd64 = -g DEBUG_CFLAGS += $(DEBUG_CFLAGS/$(BUILDARCH)) ifeq ($(DEBUG_CFLAGS/$(BUILDARCH)),) DEBUG_CFLAGS += -gstabs endif There's a history here about the size of the lib when -g is used, hence the -gstabs default. David Hiroshi Yamauchi said the following on 05/20/09 14:32: > Hi, > > If I build a fastdebug VM on Linux (based on openjdk6 b11), the > libjvm.so does not get the debug info (symbols and line numbers used > mainly in gdb). If I copy'n'paste the following lines from jvmg.make > to fastdebug.make (under hotspot/build/linux/makefiles), I get the > debug info. > > # The following lines were copied from jvmg.make > # Compiler specific DEBUG_CFLAGS are passed in from gcc.make, sparcWorks.make > DEBUG_CFLAGS/DEFAULT= $(DEBUG_CFLAGS) > DEBUG_CFLAGS/BYFILE = > $(DEBUG_CFLAGS/$@)$(DEBUG_CFLAGS/DEFAULT$(DEBUG_CFLAGS/$@) ) > CFLAGS += $(DEBUG_CFLAGS/BYFILE) > > Is this valid? > > Is there any historic reason why -g isn't used in the fastdebug build > on Linux (such as conflict between -O and -g)? > > I think the fastdebug should have -g by definition. > > Thanks, > Hiroshi From Kelly.Ohair at Sun.COM Wed May 20 09:53:36 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 20 May 2009 09:53:36 -0700 Subject: Class data sharing question Message-ID: <4A143590.7060100@sun.com> If the jdk is built with -target 7 (newer classfile format), then we are getting this from running: java -client -Xshare:dump Loading classes to share ... done. Rewriting and unlinking classes ... done. Calculating hash values for String objects .. done. Calculating fingerprints ... done. Removing unshareable information ... done. Moving pre-ordered read-only objects to shared space at 0xd7000000 ... done. Moving read-only objects to shared space at 0xd75e9950 ... done. Moving common symbols to shared space at 0xd75eb8a0 ... done. Moving remaining symbols to shared space at 0xd76bfd38 ... done. Moving string char arrays to shared space at 0xd76c0f38 ... done. Moving additional symbols to shared space at 0xd777ed60 ... Java HotSpot(TM) Client VM warning: The permanent generation read only space is not large enough to preload requested classes. Use -XX:SharedReadOnlySize= to increase the initial size of the read only space. (And I assume a non-zero exit code, since things are terminating) This example was from Solaris 10 X86. Any insights on this? Who is the resident CDS expert now? -kto From Peter.Kessler at Sun.COM Wed May 20 10:18:56 2009 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Wed, 20 May 2009 10:18:56 -0700 Subject: Class data sharing question In-Reply-To: <4A143590.7060100@sun.com> References: <4A143590.7060100@sun.com> Message-ID: <4A143B80.9010804@Sun.COM> I'm *not* the CDS expert. But SharedReadOnlySize, SharedReadWriteSize, etc. are just variables defined and given default values in globals.hpp. Presumably if we've added enough classes to the shared class archive that the defaults are not large enough, we can just change them. People will ding us for our increased footprint. We might want to figure out if the increase in the number of classes in the archive was intentional or a transient mistake. ... peter Kelly O'Hair wrote: > > If the jdk is built with -target 7 (newer classfile format), then we > are getting this from running: > > java -client -Xshare:dump > > Loading classes to share ... done. > Rewriting and unlinking classes ... done. > Calculating hash values for String objects .. done. > Calculating fingerprints ... done. > Removing unshareable information ... done. > Moving pre-ordered read-only objects to shared space at 0xd7000000 ... > done. > Moving read-only objects to shared space at 0xd75e9950 ... done. > Moving common symbols to shared space at 0xd75eb8a0 ... done. > Moving remaining symbols to shared space at 0xd76bfd38 ... done. > Moving string char arrays to shared space at 0xd76c0f38 ... done. > Moving additional symbols to shared space at 0xd777ed60 ... Java > HotSpot(TM) > Client VM warning: > The permanent generation read only space is not large enough to > preload requested classes. Use -XX:SharedReadOnlySize= to increase > the initial size of the read only space. > > (And I assume a non-zero exit code, since things are terminating) > > This example was from Solaris 10 X86. > > Any insights on this? > Who is the resident CDS expert now? > > -kto From yamauchi at google.com Wed May 20 10:58:48 2009 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Wed, 20 May 2009 10:58:48 -0700 Subject: Linux fastdebug build with debug info In-Reply-To: <4A13AA81.3060605@sun.com> References: <4A13AA81.3060605@sun.com> Message-ID: Hi David, Nice talking to you after a while! On Wed, May 20, 2009 at 12:00 AM, David Holmes - Sun Microsystems wrote: > Hi Hiroshi, > > The flags are set in gcc.make and should then be picked up by each > .make file. But in this case it appears that the linux > fastdebug.make is missing the instructions to do that! Looks like a bug to > me! Yes. That's what I thought. The fastdebug build should have some debug option baked in either -g or -gstabs. > > Regarding use of -g, hence the settings and comments from gcc.make: > > # Use the stabs format for debugging information (this is the default > # on gcc-2.91). It's good enough, has all the information about line > # numbers and local variables, and libjvm_g.so is only about 16M. > # Change this back to "-g" if you want the most expressive format. > # (warning: that could easily inflate libjvm_g.so to 150M!) > # Note: The Itanium gcc compiler crashes when using -gstabs. > DEBUG_CFLAGS/ia64 ?= -g > DEBUG_CFLAGS/amd64 = -g > DEBUG_CFLAGS += $(DEBUG_CFLAGS/$(BUILDARCH)) > ifeq ($(DEBUG_CFLAGS/$(BUILDARCH)),) > DEBUG_CFLAGS += -gstabs > endif > > There's a history here about the size of the lib when -g is used, hence the > -gstabs default. OK. I can see the size issue. In my local builds, libjvm.so is about 100M for a fastdebug (with -g) and 160M for a full debug build whereas the product build's is about 9MB. I think I can tolerate the big size for VM debugging purposes. I have a local change to force the use of -g probably for the better format of debug info. Is there a history about the Linux fastdebug build not having -g or -gstabs? Thanks, Hiroshi > > David > > Hiroshi Yamauchi said the following on 05/20/09 14:32: >> >> Hi, >> >> If I build a fastdebug VM on Linux (based on openjdk6 b11), the >> libjvm.so does not get the debug info (symbols and line numbers used >> mainly in gdb). If I copy'n'paste the following lines from jvmg.make >> to fastdebug.make (under hotspot/build/linux/makefiles), I get the >> debug info. >> >> # The following lines were copied from jvmg.make >> # Compiler specific DEBUG_CFLAGS are passed in from gcc.make, >> sparcWorks.make >> DEBUG_CFLAGS/DEFAULT= $(DEBUG_CFLAGS) >> DEBUG_CFLAGS/BYFILE = >> $(DEBUG_CFLAGS/$@)$(DEBUG_CFLAGS/DEFAULT$(DEBUG_CFLAGS/$@) ) >> CFLAGS += $(DEBUG_CFLAGS/BYFILE) >> >> Is this valid? >> >> Is there any historic reason why -g isn't used in the fastdebug build >> on Linux (such as conflict between -O and -g)? >> >> I think the fastdebug should have -g by definition. >> >> Thanks, >> Hiroshi > From David.Holmes at Sun.COM Wed May 20 16:47:41 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Thu, 21 May 2009 09:47:41 +1000 Subject: Linux fastdebug build with debug info In-Reply-To: References: <4A13AA81.3060605@sun.com> Message-ID: <4A14969D.4050301@sun.com> Hiroshi Yamauchi said the following on 05/21/09 03:58: > Nice talking to you after a while! Likewise! Small world :) > Is there a history about the Linux fastdebug build not having -g or -gstabs? The history is that it's never been present and no-one seems to have noticed/complained! :) The Solaris fastdebug.make was modified way back in mid 2000. I've filed: 6843665 in our internal bug system. David From Erik.Trimble at Sun.COM Wed May 20 16:59:47 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Wed, 20 May 2009 16:59:47 -0700 Subject: Linux fastdebug build with debug info In-Reply-To: <4A14969D.4050301@sun.com> References: <4A13AA81.3060605@sun.com> <4A14969D.4050301@sun.com> Message-ID: <4A149973.5030906@sun.com> David Holmes - Sun Microsystems wrote: > Hiroshi Yamauchi said the following on 05/21/09 03:58: >> Nice talking to you after a while! > > Likewise! Small world :) > >> Is there a history about the Linux fastdebug build not having -g or >> -gstabs? > > The history is that it's never been present and no-one seems to have > noticed/complained! :) The Solaris fastdebug.make was modified way > back in mid 2000. > > I've filed: 6843665 in our internal bug system. > > David I'm not 100% sure of the difference between our 'fastdebug' and out 'debug' builds, but one thing I do know: Linux_x64-debug isn't currently done due to _really_ excessive size on the symbol tables and associated output libary. IIRC, libjvm.so ends up being 1GB+ in size if we do a 'debug' build on linux 64-bit (this was particularly noticable on IA64 [itanium], but is also pronounced on x86_64). This may or may not have anything to do with the lack of -g being present in the makefiles. But, I thought you should know. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From Thomas.Rodriguez at Sun.COM Wed May 20 17:03:13 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 20 May 2009 17:03:13 -0700 Subject: Tiered compilation? In-Reply-To: <4A12D3EF.9090401@sun.com> References: <4A12CA14.40905@sun.com> <1242746256.29179.54.camel@macbook> <20090519153314.GH3155@redhat.com> <4A12D3EF.9090401@sun.com> Message-ID: It's slightly back burnered at the moment but it's not parked. Steve Goldman had been working on a compilation policy for tiered and had a working prototype of the policy before he passed away. Recently Igor started looking at his changes with an eye towards cleaning them up and getting them working again. Hopefully we'll know better where we stand soon. tom On May 19, 2009, at 8:44 AM, Charles Oliver Nutter wrote: > Gary Benson wrote: >> Christian Thalinger wrote: >>> AFAIK, no. Igor Veresov is currently working on tiered compilation, >>> but I don't know what the status is and if it's on the top of his >>> TODO list. >> ISTR someone on one of the open conference calls saying that tiered >> compilation was now very much on the back burner. > > That is unfortunate :( For heavy command-line environments like > JRuby it held a lot of hope for reasonably fast startup with no perf > impact. I hope something will happen to bring it forward again. > > - Charlie From mlists at juma.me.uk Wed May 20 21:59:25 2009 From: mlists at juma.me.uk (Ismael Juma) Date: Thu, 21 May 2009 04:59:25 +0000 (UTC) Subject: Tiered compilation? References: <4A12CA14.40905@sun.com> <1242746256.29179.54.camel@macbook> <20090519153314.GH3155@redhat.com> <4A12D3EF.9090401@sun.com> Message-ID: Hi Tom, Tom Rodriguez writes: > It's slightly back burnered at the moment but it's not parked. Steve > Goldman had been working on a compilation policy for tiered and had a > working prototype of the policy before he passed away. Recently Igor > started looking at his changes with an eye towards cleaning them up > and getting them working again. Hopefully we'll know better where we > stand soon. Good to hear that there are still plans around it. Best, Ismael From yamauchi at google.com Thu May 21 14:23:33 2009 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Thu, 21 May 2009 14:23:33 -0700 Subject: Linux fastdebug build with debug info In-Reply-To: <4A149973.5030906@sun.com> References: <4A13AA81.3060605@sun.com> <4A14969D.4050301@sun.com> <4A149973.5030906@sun.com> Message-ID: Thanks for filing the bug and the extra info. Without any prior known issues with turning on -g on fastdebug build on Linux, except the size issue, I think I will see if it's got any issue. What I'd like to have is the ability to see nice stacktraces from gdb without slowing down as much as the debug build. Thanks, Hiroshi On Wed, May 20, 2009 at 4:59 PM, Erik Trimble wrote: > David Holmes - Sun Microsystems wrote: >> >> Hiroshi Yamauchi said the following on 05/21/09 03:58: >>> >>> Nice talking to you after a while! >> >> Likewise! Small world :) >> >>> Is there a history about the Linux fastdebug build not having -g or >>> -gstabs? >> >> The history is that it's never been present and no-one seems to have >> noticed/complained! :) The Solaris fastdebug.make was modified way back in >> mid 2000. >> >> I've filed: 6843665 in our internal bug system. >> >> David > > I'm not 100% sure of the difference between our 'fastdebug' and out 'debug' > builds, but one thing I do know: ?Linux_x64-debug isn't currently done due > to _really_ excessive size on the symbol tables and associated output > libary. ?IIRC, libjvm.so ends up being 1GB+ in size if we do a 'debug' build > on linux 64-bit (this was particularly noticable on IA64 [itanium], but is > also pronounced on x86_64). > > > This may or may not have anything to do with the lack of -g being present in > the makefiles. But, I thought you should know. > > -- > Erik Trimble > Java System Support > Mailstop: ?usca22-123 > Phone: ?x17195 > Santa Clara, CA > Timezone: US/Pacific (GMT-0800) > > From Erik.Trimble at Sun.COM Thu May 21 16:02:20 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Thu, 21 May 2009 16:02:20 -0700 Subject: Imminent push of HSX14 to OpenJDK6... Message-ID: <1242946940.12483.18.camel@ghostbox.sfbay.sun.com> Folks, I'm just waiting to close out the voting on the sponsoring of the new HSX repositories. Voting closes friday, and approval is all but assured. On this note, I plan to update the contents of HSX14 with the latest of our bugfixes (there are a couple of important ones which need to go in before declaring HSX14 as "stable") immediately after voting closes. Thereafter, the consensus has been that I should push HSX14 into the OpenJDK6 hotspot repository. Three points here (and, I apologize in that we've discussed them before): (a) I'd like to tag the current OpenJDK6/hotspot repo with a Hg tag indicating that the current tip is the last HS11 changeset. I'd like to use a tag format similar to what we current use internally - that is, the tag will be "hsxX-bY", so, in this case, it would be "hsx11-b17". I realize this isn't strictly true right now, as the current OpenJDK6/hotspot contents are heavily modified from the original HS11-b17, but I think it will do as a starting point. (b) I'm going to look at doing a changeset transplant/migration from HSX14 to OpenJDK6, but I suspect that it's going to be a complete mess to do so. In that spirit of things, I'd like to instead do the push as a SINGLE CHANGESET. The changeset comments will include a complete list of all HS bugs fixed in HS11-b17 though HS14-b08, minus of course those which are already fixed in the OpenJDK6/hotspot repo. (c) after (b), I'm going to tag the repo with a "hsx14-b08" tag, to indicate this is where things started for HSX14 in the OpenJDK6/hotspot repo. Timetable: Assuming no objections, (a) will be done no later than Saturday (23.05.2009). I'll work on (b) next week, so (b) should be done no later than Friday (29.05.2009), with (c) to be done immediately after (b). -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From Erik.Trimble at Sun.COM Thu May 21 17:04:58 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Thu, 21 May 2009 17:04:58 -0700 Subject: Imminent push of HSX14 to OpenJDK6... In-Reply-To: <4A15E1DC.2070201@sun.com> References: <1242946940.12483.18.camel@ghostbox.sfbay.sun.com> <4A15E1DC.2070201@sun.com> Message-ID: <1242950698.12483.26.camel@ghostbox.sfbay.sun.com> Oops. Typo on my part. The push of HSX14 will be HSX14 Build 16, NOT Build 08. -Erik On Thu, 2009-05-21 at 17:21 -0600, Daniel D. Daugherty wrote: > Why HS15-b08/hsx14-b08? The current HSX-14 build is HSX-14-B16... > > Dan > > > Erik Trimble wrote: > > The changeset comments will include a complete list > > of all HS bugs fixed in HS11-b17 though HS14-b08, minus of course those > > which are already fixed in the OpenJDK6/hotspot repo. > > > > (c) after (b), I'm going to tag the repo with a "hsx14-b08" tag, to > > indicate this is where things started for HSX14 in the OpenJDK6/hotspot > > repo. > > -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From gnu_andrew at member.fsf.org Thu May 21 17:34:48 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 22 May 2009 01:34:48 +0100 Subject: Imminent push of HSX14 to OpenJDK6... In-Reply-To: <1242946940.12483.18.camel@ghostbox.sfbay.sun.com> References: <1242946940.12483.18.camel@ghostbox.sfbay.sun.com> Message-ID: <17c6771e0905211734i58ea23c3ge305a71e76d440da@mail.gmail.com> 2009/5/22 Erik Trimble : > Folks, > > I'm just waiting to close out the voting on the sponsoring of the new > HSX repositories. Voting closes friday, and approval is all but assured. > > > On this note, I plan to update the contents of HSX14 with the latest of > our bugfixes (there are a couple of important ones which need to go in > before declaring HSX14 as "stable") immediately after voting closes. > > Thereafter, the consensus has been that I should push HSX14 into the > OpenJDK6 hotspot repository. > What consensus? I just remember the discussion being left after we could maintain it in OJ6 or in HSX14. I really don't see the point in having a clone of it in OpenJDK6 which has to be continuously synced. > Three points here (and, I apologize in that we've discussed them > before): > > > (a) I'd like to tag the current OpenJDK6/hotspot repo with a Hg tag > indicating that the current tip is the last HS11 changeset. ?I'd like to > use a tag format similar to what we current use internally - that is, > the tag will be "hsxX-bY", so, in this case, it would be "hsx11-b17". ?I > realize this isn't strictly true right now, as the current > OpenJDK6/hotspot contents are heavily modified from the original > HS11-b17, but I think it will do as a starting point. > Why is this not being done in the HSX repo? > (b) I'm going to look at doing a changeset transplant/migration from > HSX14 to OpenJDK6, but I suspect that it's going to be a complete mess > to do so. ?In that spirit of things, I'd like to instead do the push as > a SINGLE CHANGESET. ?The changeset comments will include a complete list > of all HS bugs fixed in HS11-b17 though HS14-b08, minus of course those > which are already fixed in the OpenJDK6/hotspot repo. > As I already reported, the different between current OpenJDK6 HotSpot and changeset 0 in HSX are whitespace differences. A forced pull of 0 and a merge would then allow the other changesets to be placed on top. > (c) after (b), I'm going to tag the repo with a "hsx14-b08" tag, to > indicate this is where things started for HSX14 in the OpenJDK6/hotspot > repo. > What is special about b08? HSX is on b13 IIRC. > > > Timetable: > > Assuming no objections, (a) will be done no later than Saturday > (23.05.2009). ?I'll work on (b) next week, so (b) should be done no > later than Friday (29.05.2009), with (c) to be done immediately after > (b). > > > > > -- > Erik Trimble > Java System Support > Mailstop: ?usca22-123 > Phone: ?x17195 > Santa Clara, CA > Timezone: US/Pacific (GMT-0800) > > -- 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 Mon May 25 04:07:21 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 25 May 2009 13:07:21 +0200 Subject: Linux fastdebug build with debug info In-Reply-To: <4A149973.5030906@sun.com> References: <4A13AA81.3060605@sun.com> <4A14969D.4050301@sun.com> <4A149973.5030906@sun.com> Message-ID: On 5/21/09, Erik Trimble wrote: > David Holmes - Sun Microsystems wrote: > > > Hiroshi Yamauchi said the following on 05/21/09 03:58: > > > > > Nice talking to you after a while! > > > > > > > Likewise! Small world :) > > > > > > > Is there a history about the Linux fastdebug build not having -g or > -gstabs? > > > > > > > The history is that it's never been present and no-one seems to have > noticed/complained! :) The Solaris fastdebug.make was modified way back in > mid 2000. > > > > I've filed: 6843665 in our internal bug system. > > > > David > > > I'm not 100% sure of the difference between our 'fastdebug' and out 'debug' > builds, but one thing I do know: Linux_x64-debug isn't currently done due > to _really_ excessive size on the symbol tables and associated output > libary. IIRC, libjvm.so ends up being 1GB+ in size if we do a 'debug' build > on linux 64-bit (this was particularly noticable on IA64 [itanium], but is > also pronounced on x86_64). > I think these are really old numbers. Building the Java 6 server VM with gcc 4.1 on Linux results in the following sizes of libjvm.so for us: i386 ----- FASTDEBUG with -g -O3 : 141M PRODUCT with -g -O3: 182M amd64 --------- FASTDEBUG with -g -O3 : 153M PRODUCT with -g -O3: 192M ia64 ------ FASTDEBUG with -g -O3 : 224M PRODUCT with -g -O3: 262M I can only guess that the PRODUCT builds are bigger because of the excessive inlineing with O3. I also think the comments in the Makefile which recommend the usage of "-gstabs" are very old and outdated by newer versions of gcc. Using "-g" for a fastdebug build should be ok and the default from my point of view. Regards, Volker > > This may or may not have anything to do with the lack of -g being present > in the makefiles. But, I thought you should know. > > -- > Erik Trimble > Java System Support > Mailstop: usca22-123 > Phone: x17195 > Santa Clara, CA > Timezone: US/Pacific (GMT-0800) > > From David.Holmes at Sun.COM Mon May 25 04:36:08 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Mon, 25 May 2009 21:36:08 +1000 Subject: Linux fastdebug build with debug info In-Reply-To: References: <4A13AA81.3060605@sun.com> <4A14969D.4050301@sun.com> <4A149973.5030906@sun.com> Message-ID: <4A1A82A8.20805@sun.com> Hi Volker, Compare -g with -gstabs. With a particular VM version is see 146MB vs 24MB for the debug library. We use -g for the 64-bit VM by default, but not for 32-bit. Based on those figures oyu gave it looks like we build with debugging info at the gcc-level for the product libs as well. Anyway seems like something that should be settable externally as the builder chooses. Cheers, David Holmes Volker Simonis said the following on 05/25/09 21:07: > On 5/21/09, Erik Trimble wrote: >> David Holmes - Sun Microsystems wrote: >> >>> Hiroshi Yamauchi said the following on 05/21/09 03:58: >>> >>>> Nice talking to you after a while! >>>> >>> Likewise! Small world :) >>> >>> >>>> Is there a history about the Linux fastdebug build not having -g or >> -gstabs? >>> The history is that it's never been present and no-one seems to have >> noticed/complained! :) The Solaris fastdebug.make was modified way back in >> mid 2000. >>> I've filed: 6843665 in our internal bug system. >>> >>> David >>> >> I'm not 100% sure of the difference between our 'fastdebug' and out 'debug' >> builds, but one thing I do know: Linux_x64-debug isn't currently done due >> to _really_ excessive size on the symbol tables and associated output >> libary. IIRC, libjvm.so ends up being 1GB+ in size if we do a 'debug' build >> on linux 64-bit (this was particularly noticable on IA64 [itanium], but is >> also pronounced on x86_64). >> > > I think these are really old numbers. Building the Java 6 server VM > with gcc 4.1 on Linux results in the following sizes of libjvm.so for > us: > > i386 > ----- > FASTDEBUG with -g -O3 : 141M > PRODUCT with -g -O3: 182M > > amd64 > --------- > FASTDEBUG with -g -O3 : 153M > PRODUCT with -g -O3: 192M > > ia64 > ------ > FASTDEBUG with -g -O3 : 224M > PRODUCT with -g -O3: 262M > > I can only guess that the PRODUCT builds are bigger because of the > excessive inlineing with O3. > > I also think the comments in the Makefile which recommend the usage of > "-gstabs" are very old and outdated by newer versions of gcc. Using > "-g" for a fastdebug build should be ok and the default from my point > of view. > > Regards, > Volker > > >> This may or may not have anything to do with the lack of -g being present >> in the makefiles. But, I thought you should know. >> >> -- >> Erik Trimble >> Java System Support >> Mailstop: usca22-123 >> Phone: x17195 >> Santa Clara, CA >> Timezone: US/Pacific (GMT-0800) >> >> From gbenson at redhat.com Tue May 26 08:12:02 2009 From: gbenson at redhat.com (Gary Benson) Date: Tue, 26 May 2009 16:12:02 +0100 Subject: 0xdeaddeaf Message-ID: <20090526151202.GB3166@redhat.com> Hi all, I've recently started seeing a crash on amd64 using the zero-assembler port which I'm trying to debug. A lot of the local variables in the crash dump seem to have their top half replaced with 0xdeaddeaf, like so: 0x7fab7ece2338: istate->_self_link = 0x00007fab7ece22b8 0x7fab7ece2340: frame_type = INTERPRETER_FRAME 0x7fab7ece2348: next_frame = 0x00007fab7ece23f0 0x7fab7ece2350: local[1] = 0xdeaddeaf020c1370 0x7fab7ece2358: local[0] = 0xdeaddeaf7ece2380 0x7fab7ece2360: istate->_thread = 0x0000000001acf660 Is this something new? It's not something I've seen before. In what circumstances would the VM write 0xdeaddeaf into stack slots? Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Tue May 26 08:55:31 2009 From: gbenson at redhat.com (Gary Benson) Date: Tue, 26 May 2009 16:55:31 +0100 Subject: 0xdeaddeaf In-Reply-To: <20090526151202.GB3166@redhat.com> References: <20090526151202.GB3166@redhat.com> Message-ID: <20090526155531.GC3166@redhat.com> Gary Benson wrote: > In what circumstances would the VM write 0xdeaddeaf into stack > slots? I just answered my own question, sorry for the noise :) Cheers, Gary -- http://gbenson.net/ From keith.mcguigan at sun.com Wed May 27 10:59:01 2009 From: keith.mcguigan at sun.com (keith.mcguigan at sun.com) Date: Wed, 27 May 2009 17:59:01 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20090527175909.071B5EAD7@hg.openjdk.java.net> Changeset: 47ffceb239d0 Author: thurka Date: 2009-05-20 09:36 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/47ffceb239d0 6839599: JVM crash while profiling Tomcat and Liferay Summary: constantPoolOopDesc::copy_cpool_bytes() - do the brute-force search search through 'tbl' when SymbolTable::lookup_only() returns NULL Reviewed-by: kamg ! src/share/vm/oops/constantPoolOop.cpp Changeset: f1f3a2719a55 Author: xlu Date: 2009-05-22 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f1f3a2719a55 6843580: JavaThread.getStackBase throws sun.jvm.hotspot.WrongTypeException invoked by jstack Reviewed-by: phh, dice, never, swamyv ! agent/src/share/classes/sun/jvm/hotspot/runtime/JavaThread.java From Rob.Saccoccio at sas.com Fri May 29 12:06:30 2009 From: Rob.Saccoccio at sas.com (Rob Saccoccio) Date: Fri, 29 May 2009 15:06:30 -0400 Subject: __stack_chk_fail@@GLIBC_2.4 dependency Message-ID: I'm building hotspot on X86_64 Fedora 10 with gcc 4.3.2. The resulting libjvm.so has a dependency on __stack_chk_fail@@GLIBC_2.4. This is fine until I try to move it to a linux box that only has glibc 2.3.4. Building with "-fno-stack-protector -U_FORTIFY_SOURCE" doesn't eliminate the dependency and apbuild didn't help either. I don't know where the dependency is coming from. Any help would be most welcome. Rob From martinrb at google.com Fri May 29 16:38:11 2009 From: martinrb at google.com (Martin Buchholz) Date: Fri, 29 May 2009 16:38:11 -0700 Subject: __stack_chk_fail@@GLIBC_2.4 dependency In-Reply-To: References: Message-ID: <1ccfd1c10905291638q1473d1fbs46503f02e0eb98b1@mail.gmail.com> My standard recommendation is to build on the oldest version of a platform that you intend to support at runtime. For the particular case of linux, I recommend building on Ubuntu dapper or equivalent system with glibc 2.3.x. Martin On Fri, May 29, 2009 at 12:06, Rob Saccoccio wrote: > I'm building hotspot on X86_64 Fedora 10 with gcc 4.3.2. The resulting > libjvm.so has a dependency on __stack_chk_fail@@GLIBC_2.4. This is fine > until I try to move it to a linux box that only has glibc 2.3.4. > > Building with "-fno-stack-protector -U_FORTIFY_SOURCE" doesn't eliminate > the dependency and apbuild didn't help either. > > I don't know where the dependency is coming from. > > Any help would be most welcome. > > Rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090529/db9a8f18/attachment.html From Rob.Saccoccio at sas.com Fri May 29 17:45:48 2009 From: Rob.Saccoccio at sas.com (Rob Saccoccio) Date: Fri, 29 May 2009 20:45:48 -0400 Subject: __stack_chk_fail@@GLIBC_2.4 dependency In-Reply-To: <1ccfd1c10905291638q1473d1fbs46503f02e0eb98b1@mail.gmail.com> References: <1ccfd1c10905291638q1473d1fbs46503f02e0eb98b1@mail.gmail.com> Message-ID: Thanks for the quick reply Martin. I figured it out (as is often the case once I post for help ;). The build links statically against stdc++ and that was built with stack protection. Linking stdc++ dynamically eliminated the dependency on __stack_chk_fail. Two new()s and a delete() are being picked up from stdc++. Anyone have a guess at the badness of making these calls dynamic? My stuff spends most of its time in loops crunching numbers so I don't expect it to be too big deal - at least for the work I need to complete this week. Rob From: Martin Buchholz [mailto:martinrb at google.com] Sent: Friday, May 29, 2009 7:38 PM To: Rob Saccoccio Cc: hotspot-dev at openjdk.java.net Subject: Re: __stack_chk_fail@@GLIBC_2.4 dependency My standard recommendation is to build on the oldest version of a platform that you intend to support at runtime. For the particular case of linux, I recommend building on Ubuntu dapper or equivalent system with glibc 2.3.x. Martin On Fri, May 29, 2009 at 12:06, Rob Saccoccio > wrote: I'm building hotspot on X86_64 Fedora 10 with gcc 4.3.2. The resulting libjvm.so has a dependency on __stack_chk_fail@@GLIBC_2.4. This is fine until I try to move it to a linux box that only has glibc 2.3.4. Building with "-fno-stack-protector -U_FORTIFY_SOURCE" doesn't eliminate the dependency and apbuild didn't help either. I don't know where the dependency is coming from. Any help would be most welcome. Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090529/cbe7091e/attachment.html