Re: 7099119: Remove unused dlinfo local variable in launcher code
On 11/30/2012 03:10 PM, Shi Jun wrote: On 11/29/2012 6:40 PM, Alan Bateman wrote: On 29/11/2012 07:17, Shi Jun wrote: Hi all, Previously 7099119 is fixed in the following changeset: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd55467dd1f2, but this change is lost during the Mac port merging changes 7113349 and 7146424. Hereby I raise this thread again. Webrev: http://cr.openjdk.java.net/~zhangshj/7099119/webrev.00/ Previous discuss thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-October/007872.html I don't know this slipped it, perhaps it was due to the refactoring. In any case your change looks fine. -Alan Thanks, Alan. Hi Jonathan, Could you help to push the change? Hi Chance, I'm getting an error of, remote: Bugid 7099119 already used in this repository, in revision 4607 Could you please create another sun bug for this issue? Thanks and best regards! - Jonathan
Re: 7099119: Remove unused dlinfo local variable in launcher code
On 30/11/2012 08:49, Jonathan Lu wrote: Hi Chance, I'm getting an error of, remote: Bugid 7099119 already used in this repository, in revision 4607 Could you please create another sun bug for this issue? Right, you can't use a bug/issue number in more than one change-set in the same repository. I've submitted another one that you can use: JDK-8004211: Remove unused dlinfo local variable in launcher code -Alan
Re: 7099119: Remove unused dlinfo local variable in launcher code
On 11/30/2012 5:27 PM, Jonathan Lu wrote: On 11/30/2012 04:58 PM, Alan Bateman wrote: On 30/11/2012 08:49, Jonathan Lu wrote: Hi Chance, I'm getting an error of, remote: Bugid 7099119 already used in this repository, in revision 4607 Could you please create another sun bug for this issue? Right, you can't use a bug/issue number in more than one change-set in the same repository. I've submitted another one that you can use: JDK-8004211: Remove unused dlinfo local variable in launcher code -Alan Thanks, Alan. The patch has been pushed to http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e988de7465d4 Best regards! - Jonathan Thanks, Alan and Jonathan. -- Regards, Shi Jun Zhang
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
On 30/11/2012 02:03, David Holmes wrote: On 30/11/2012 12:44 AM, Chris Hegarty wrote: On 11/29/2012 05:50 AM, David Holmes wrote: ... I don't agree that we need to describe what the default implementation does, for two reasons: 1. Normal methods don't usually specify how they are implemented - it is an implementation detail. The default simply indicates that this method does have an implementation and you should expect that implementation to obey the contract of the method. 2. It is not obvious to me that the JDK's choice for a default implementation has to be _the_ only possible implementation choice. In many/most cases there will be a very obvious choice, but that doesn't mean that all suppliers of OpenJDK classes have to be locked in to that choice. This is certainly interesting, and something I've wondered for a while now. If java.util.Iterator is to ever be fitted with a default implementation of remove ( to throw UnsupportedOperationException ), then it would clearly need to be part of the spec, and not an implementation detail of OpenJDK. Otherwise, what's the point, every developer will still have to implement it because they cannot be guaranteed of it's behavior. I think optional methods are a bit of a special case here because they don't have to work. It's the end user of a class that needs to understand if they can use remove() to actually do a removal. The developer of the class can inherit whatever default implementations Iterator provides, as long as they don't mind what they get. If they do mind ie they need a real remove(), then they will have to implement it themselves and in the process document that fact. The end user has to look at the docs for the concrete class and follow through to determine whether it's iterator().remove() is optional or not. Put another way, a default method is great for adding a new method to types that have not yet been revised to handle the new method. As a developer once you revise your class you should make a conscious implementation choice in my opinion and not rely on the default unless you truly don't care what it does. Sorry David, I've not been following lambda that closely, but (in my opinion) if default methods do not, or cannot, have defined semantics then I really think it is limiting. Maybe Iterator is a bad example, but I will continue with it anyway. In many cases developers of iterator().remove() want it to throw, if this is not defined in Iterator's default remove method then every Iterator subclass will still have to define its own remove that throws. For this particular case at least (if it were to ever happen), I would like to see specification added to remove that defines the default implementation. -Chris. But maybe we kid ourselves when we give this illusion of flexibility in implementation. David -Chris.
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
On 30/11/2012 7:58 PM, Chris Hegarty wrote: On 30/11/2012 02:03, David Holmes wrote: On 30/11/2012 12:44 AM, Chris Hegarty wrote: On 11/29/2012 05:50 AM, David Holmes wrote: ... I don't agree that we need to describe what the default implementation does, for two reasons: 1. Normal methods don't usually specify how they are implemented - it is an implementation detail. The default simply indicates that this method does have an implementation and you should expect that implementation to obey the contract of the method. 2. It is not obvious to me that the JDK's choice for a default implementation has to be _the_ only possible implementation choice. In many/most cases there will be a very obvious choice, but that doesn't mean that all suppliers of OpenJDK classes have to be locked in to that choice. This is certainly interesting, and something I've wondered for a while now. If java.util.Iterator is to ever be fitted with a default implementation of remove ( to throw UnsupportedOperationException ), then it would clearly need to be part of the spec, and not an implementation detail of OpenJDK. Otherwise, what's the point, every developer will still have to implement it because they cannot be guaranteed of it's behavior. I think optional methods are a bit of a special case here because they don't have to work. It's the end user of a class that needs to understand if they can use remove() to actually do a removal. The developer of the class can inherit whatever default implementations Iterator provides, as long as they don't mind what they get. If they do mind ie they need a real remove(), then they will have to implement it themselves and in the process document that fact. The end user has to look at the docs for the concrete class and follow through to determine whether it's iterator().remove() is optional or not. Put another way, a default method is great for adding a new method to types that have not yet been revised to handle the new method. As a developer once you revise your class you should make a conscious implementation choice in my opinion and not rely on the default unless you truly don't care what it does. Sorry David, I've not been following lambda that closely, but (in my opinion) if default methods do not, or cannot, have defined semantics then I really think it is limiting. Maybe Iterator is a bad example, but I will continue with it anyway. In many cases developers of iterator().remove() want it to throw, if this is not defined in Iterator's default remove method then every Iterator subclass will still have to define its own remove that throws. For this particular case at least (if it were to ever happen), I would like to see specification added to remove that defines the default implementation. The supplied default implementation will document that it throws. But does that mean it is the only possible default implementation, ever? Again Iterator.remove() is not a great example. default methods are no different to other concrete methods in my opinion. David -- -Chris. But maybe we kid ourselves when we give this illusion of flexibility in implementation. David -Chris.
Re: Code Review Request: 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by couldn't get file lock
On 30/11/2012 02:04, Kurchi Hazra wrote: Apologies for the extreme delay. I added the bug id, and checked that setting the userRoot=. will result in the JTwork/scratch directory being used to store the preferences. I think we had concluded that othervm is the correct choice for running a test when setting the -Djava.util.prefs.userRoot property. Updated webrev: http://cr.openjdk.java.net/~khazra/7197662/webrev.01/ Note that the -Djava.util.prefs.userRoot property is only honored by Linux/Solaris implementations. Windows and Mac OS will continue to use the user's home directory, or the default location that the respective platform uses to store preferences. I think what you have is fine as it will address the case where the user's home directory is NFS/auto-mounted (which I think is where this issue comes up periodically). -Alan
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
On 11/30/2012 01:50 PM, Lance Andersen - Oracle wrote: On Nov 30, 2012, at 4:58 AM, Chris Hegarty wrote: On 30/11/2012 02:03, David Holmes wrote: On 30/11/2012 12:44 AM, Chris Hegarty wrote: On 11/29/2012 05:50 AM, David Holmes wrote: ... I don't agree that we need to describe what the default implementation does, for two reasons: 1. Normal methods don't usually specify how they are implemented - it is an implementation detail. The default simply indicates that this method does have an implementation and you should expect that implementation to obey the contract of the method. 2. It is not obvious to me that the JDK's choice for a default implementation has to be _the_ only possible implementation choice. In many/most cases there will be a very obvious choice, but that doesn't mean that all suppliers of OpenJDK classes have to be locked in to that choice. This is certainly interesting, and something I've wondered for a while now. If java.util.Iterator is to ever be fitted with a default implementation of remove ( to throw UnsupportedOperationException ), then it would clearly need to be part of the spec, and not an implementation detail of OpenJDK. Otherwise, what's the point, every developer will still have to implement it because they cannot be guaranteed of it's behavior. I think optional methods are a bit of a special case here because they don't have to work. It's the end user of a class that needs to understand if they can use remove() to actually do a removal. The developer of the class can inherit whatever default implementations Iterator provides, as long as they don't mind what they get. If they do mind ie they need a real remove(), then they will have to implement it themselves and in the process document that fact. The end user has to look at the docs for the concrete class and follow through to determine whether it's iterator().remove() is optional or not. Put another way, a default method is great for adding a new method to types that have not yet been revised to handle the new method. As a developer once you revise your class you should make a conscious implementation choice in my opinion and not rely on the default unless you truly don't care what it does. Sorry David, I've not been following lambda that closely, but (in my opinion) if default methods do not, or cannot, have defined semantics then I really think it is limiting. Maybe Iterator is a bad example, but I will continue with it anyway. In many cases developers of iterator().remove() want it to throw, if this is not defined in Iterator's default remove method then every Iterator subclass will still have to define its own remove that throws. For this particular case at least (if it were to ever happen), I would like to see specification added to remove that defines the default implementation. I had wondered about this as well and had a brief email exchange with Mike. I thought a new javadoc tag might also be something to consider. @implementation ? For JDBC, I am thinking of leveraging default methods to throw a specific exception (maybe IllegalStateException?) if the method must be implemented by the driver vendor an UnsupportedOperationException is better for that. or a SQLFeatureNotSupportedException for methods which may be optional based on the backend support. Rémi
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
On Nov 30, 2012, at 7:56 AM, Remi Forax wrote: On 11/30/2012 01:50 PM, Lance Andersen - Oracle wrote: On Nov 30, 2012, at 4:58 AM, Chris Hegarty wrote: On 30/11/2012 02:03, David Holmes wrote: On 30/11/2012 12:44 AM, Chris Hegarty wrote: On 11/29/2012 05:50 AM, David Holmes wrote: ... I don't agree that we need to describe what the default implementation does, for two reasons: 1. Normal methods don't usually specify how they are implemented - it is an implementation detail. The default simply indicates that this method does have an implementation and you should expect that implementation to obey the contract of the method. 2. It is not obvious to me that the JDK's choice for a default implementation has to be _the_ only possible implementation choice. In many/most cases there will be a very obvious choice, but that doesn't mean that all suppliers of OpenJDK classes have to be locked in to that choice. This is certainly interesting, and something I've wondered for a while now. If java.util.Iterator is to ever be fitted with a default implementation of remove ( to throw UnsupportedOperationException ), then it would clearly need to be part of the spec, and not an implementation detail of OpenJDK. Otherwise, what's the point, every developer will still have to implement it because they cannot be guaranteed of it's behavior. I think optional methods are a bit of a special case here because they don't have to work. It's the end user of a class that needs to understand if they can use remove() to actually do a removal. The developer of the class can inherit whatever default implementations Iterator provides, as long as they don't mind what they get. If they do mind ie they need a real remove(), then they will have to implement it themselves and in the process document that fact. The end user has to look at the docs for the concrete class and follow through to determine whether it's iterator().remove() is optional or not. Put another way, a default method is great for adding a new method to types that have not yet been revised to handle the new method. As a developer once you revise your class you should make a conscious implementation choice in my opinion and not rely on the default unless you truly don't care what it does. Sorry David, I've not been following lambda that closely, but (in my opinion) if default methods do not, or cannot, have defined semantics then I really think it is limiting. Maybe Iterator is a bad example, but I will continue with it anyway. In many cases developers of iterator().remove() want it to throw, if this is not defined in Iterator's default remove method then every Iterator subclass will still have to define its own remove that throws. For this particular case at least (if it were to ever happen), I would like to see specification added to remove that defines the default implementation. I had wondered about this as well and had a brief email exchange with Mike. I thought a new javadoc tag might also be something to consider. @implementation ? For JDBC, I am thinking of leveraging default methods to throw a specific exception (maybe IllegalStateException?) if the method must be implemented by the driver vendor an UnsupportedOperationException is better for that. Agree that could be a better choice or a SQLFeatureNotSupportedException for methods which may be optional based on the backend support. Rémi Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
The problem for an API such as JDBC is that the implementation is going to be specific to the driver and backend so providing a default implementation just won't work. This allows existing drivers to compile as they finish their implementation and complete their migration to the new version of the API. On Nov 30, 2012, at 8:14 AM, Ricky Clarkson wrote: What is the benefit of throwing an IllegalStateException in a default method over not providing any default method so that the compiler and runtime make sure concrete subtypes provide an implementation? On Nov 30, 2012 9:54 AM, Lance Andersen - Oracle lance.ander...@oracle.com wrote: On Nov 30, 2012, at 4:58 AM, Chris Hegarty wrote: On 30/11/2012 02:03, David Holmes wrote: On 30/11/2012 12:44 AM, Chris Hegarty wrote: On 11/29/2012 05:50 AM, David Holmes wrote: ... I don't agree that we need to describe what the default implementation does, for two reasons: 1. Normal methods don't usually specify how they are implemented - it is an implementation detail. The default simply indicates that this method does have an implementation and you should expect that implementation to obey the contract of the method. 2. It is not obvious to me that the JDK's choice for a default implementation has to be _the_ only possible implementation choice. In many/most cases there will be a very obvious choice, but that doesn't mean that all suppliers of OpenJDK classes have to be locked in to that choice. This is certainly interesting, and something I've wondered for a while now. If java.util.Iterator is to ever be fitted with a default implementation of remove ( to throw UnsupportedOperationException ), then it would clearly need to be part of the spec, and not an implementation detail of OpenJDK. Otherwise, what's the point, every developer will still have to implement it because they cannot be guaranteed of it's behavior. I think optional methods are a bit of a special case here because they don't have to work. It's the end user of a class that needs to understand if they can use remove() to actually do a removal. The developer of the class can inherit whatever default implementations Iterator provides, as long as they don't mind what they get. If they do mind ie they need a real remove(), then they will have to implement it themselves and in the process document that fact. The end user has to look at the docs for the concrete class and follow through to determine whether it's iterator().remove() is optional or not. Put another way, a default method is great for adding a new method to types that have not yet been revised to handle the new method. As a developer once you revise your class you should make a conscious implementation choice in my opinion and not rely on the default unless you truly don't care what it does. Sorry David, I've not been following lambda that closely, but (in my opinion) if default methods do not, or cannot, have defined semantics then I really think it is limiting. Maybe Iterator is a bad example, but I will continue with it anyway. In many cases developers of iterator().remove() want it to throw, if this is not defined in Iterator's default remove method then every Iterator subclass will still have to define its own remove that throws. For this particular case at least (if it were to ever happen), I would like to see specification added to remove that defines the default implementation. I had wondered about this as well and had a brief email exchange with Mike. I thought a new javadoc tag might also be something to consider. For JDBC, I am thinking of leveraging default methods to throw a specific exception (maybe IllegalStateException?) if the method must be implemented by the driver vendor or a SQLFeatureNotSupportedException for methods which may be optional based on the backend support. -Chris. But maybe we kid ourselves when we give this illusion of flexibility in implementation. David -Chris. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
hg: jdk8/tl/langtools: 4 new changesets
Changeset: 4f9853659bf1 Author:mcimadamore Date: 2012-11-30 15:14 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4f9853659bf1 8004105: Expression statement lambdas should be void-compatible Summary: Fix lambda compatibility rules as per latest EDR Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/tools/javac/lambda/LambdaConv21.java ! test/tools/javac/lambda/LambdaConv21.out ! test/tools/javac/lambda/VoidCompatibility.out Changeset: 34d1ebaf4645 Author:mcimadamore Date: 2012-11-30 15:14 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/34d1ebaf4645 8004102: Add support for generic functional descriptors Summary: Method references are allowed to have a generic functional interface descriptor target Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java + test/tools/javac/diags/examples/InvalidGenericLambdaTarget.java + test/tools/javac/lambda/FunctionalInterfaceConversionTest.java - test/tools/javac/lambda/LambdaConversionTest.java + test/tools/javac/lambda/MethodReference57.java + test/tools/javac/lambda/MethodReference58.java + test/tools/javac/lambda/MethodReference58.out Changeset: 9b26c96f5138 Author:mcimadamore Date: 2012-11-30 15:14 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9b26c96f5138 8004101: Add checks for method reference well-formedness Summary: Bring method reference type-checking in sync with latest EDR Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/diags/examples/StaticBoundMref.java + test/tools/javac/diags/examples/StaticMrefWithTargs.java ! test/tools/javac/lambda/MethodReference30.java + test/tools/javac/lambda/MethodReference55.java + test/tools/javac/lambda/MethodReference55.out + test/tools/javac/lambda/MethodReference56.java + test/tools/javac/lambda/MethodReference56.out ! test/tools/javac/lambda/methodReference/MethodRef1.java ! test/tools/javac/lambda/methodReference/SamConversion.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java Changeset: f6f1fd261f57 Author:mcimadamore Date: 2012-11-30 15:14 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f6f1fd261f57 8002099: Add support for intersection types in cast expression Summary: Add parser and type-checking support for intersection types in cast expressions Reviewed-by: jjg + src/share/classes/com/sun/source/tree/IntersectionTypeTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java + src/share/classes/javax/lang/model/type/IntersectionType.java ! src/share/classes/javax/lang/model/type/TypeKind.java ! src/share/classes/javax/lang/model/type/TypeVisitor.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java + test/tools/javac/cast/intersection/IntersectionTypeCastTest.java + test/tools/javac/cast/intersection/IntersectionTypeParserTest.java + test/tools/javac/cast/intersection/model/Check.java + test/tools/javac/cast/intersection/model/IntersectionTypeInfo.java + test/tools/javac/cast/intersection/model/Member.java + test/tools/javac/cast/intersection/model/Model01.java + test/tools/javac/cast/intersection/model/ModelChecker.java +
RFR- 7200297 jdwp and hprof code do not handle multiple sun.boot.library.path elements correctly
This bug was reviewed by serviceability and hotspot-runtime-dev lists since it dealt with jvmti agent code. Comments welcome. The intent is to push into tl/jdk tree and then eventually back into jdk7u-dev hopefully. Webrev here: http://cr.openjdk.java.net/~bpittore/7200297/webrev.04/ And previous reviews here: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-November/004801.html thanks, bill
Re: RFR- 7200297 jdwp and hprof code do not handle multiple sun.boot.library.path elements correctly
On 30/11/2012 15:16, BILL PITTORE wrote: This bug was reviewed by serviceability and hotspot-runtime-dev lists since it dealt with jvmti agent code. Comments welcome. The intent is to push into tl/jdk tree and then eventually back into jdk7u-dev hopefully. Webrev here: http://cr.openjdk.java.net/~bpittore/7200297/webrev.04/ And previous reviews here: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-November/004801.html thanks, bill Bill - if you already have a reviewer then just go ahead and push the fix, you don't need to get an additional review here. -Alan
Re: RFR- 7200297 jdwp and hprof code do not handle multiple sun.boot.library.path elements correctly
Ok, Thanks. David Holmes asked that I send to this alias and he would re-review then push it for me. bill | On 11/30/2012 10:37 AM, Alan Bateman wrote: | On 30/11/2012 15:16, BILL PITTORE wrote: This bug was reviewed by serviceability and hotspot-runtime-dev lists since it dealt with jvmti agent code. Comments welcome. The intent is to push into tl/jdk tree and then eventually back into jdk7u-dev hopefully. Webrev here: http://cr.openjdk.java.net/~bpittore/7200297/webrev.04/ And previous reviews here: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-November/004801.html thanks, bill Bill - if you already have a reviewer then just go ahead and push the fix, you don't need to get an additional review here. -Alan
hg: jdk8/tl/jdk: 7165762: (aio) Default thread pool should be configured so that threads terminated after a timeout period
Changeset: c370048be8fc Author:alanb Date: 2012-11-30 16:29 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c370048be8fc 7165762: (aio) Default thread pool should be configured so that threads terminated after a timeout period Reviewed-by: chegar ! src/share/classes/sun/nio/ch/ThreadPool.java
hg: jdk8/tl/jdk: 8004110: Remove debug code form sun/reflect/annotation/AnnotationSupport.java
Changeset: e7edb0da9c6a Author:jfranck Date: 2012-11-30 09:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7edb0da9c6a 8004110: Remove debug code form sun/reflect/annotation/AnnotationSupport.java Reviewed-by: jjg, darcy ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java
Review Request: 8004201: add reducers to primitive type wrappers
Hi Requesting review for some basic functionality related to lambdas - Add min, max, sum methods to the primitive wrapper classes - Byte, Short, Integer, Long, Float, Double and Character so as to be able to use them as reducers in lambda expressions. Add and, or, xor methods to Boolean. http://cr.openjdk.java.net/~akhil/8004201.0/webrev/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201 Thanks
Re: Review Request: 8004201: add reducers to primitive type wrappers
Hi Akhil, At least for Integer.min/max you may want to use Math.min/max - these are jit intrinsics. I'd probably use the Math methods for all matching types (int, long, float, double) to cover the bases. Thanks Sent from my phone On Nov 30, 2012 1:45 PM, Akhil Arora akhil.ar...@oracle.com wrote: Hi Requesting review for some basic functionality related to lambdas - Add min, max, sum methods to the primitive wrapper classes - Byte, Short, Integer, Long, Float, Double and Character so as to be able to use them as reducers in lambda expressions. Add and, or, xor methods to Boolean. http://cr.openjdk.java.net/~**akhil/8004201.0/webrev/http://cr.openjdk.java.net/~akhil/8004201.0/webrev/ http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8004201http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201 Thanks
Re: Request for review (XXS): JDK-8004066: TEST_BUG: test/java/lang/Math/DivModTests.java assumes ArithmeticException message
On Nov 30, 2012, at 10:48 AM, Krystal Mo krystal...@oracle.com wrote: Hi all, Could I get a couple of review for this small change, please? And could someone from the JDK side sponsor this change? Bug: https://jbs.oracle.com/bugs/browse/JDK-8004066 Webrev: http://cr.openjdk.java.net/~kmo/8004066/webrev.00/ Looks good to me. -- Chris The DivModTest introduced in JDK-6282196 [1] checks the contents of the exception message, but that message isn't specified in JavaDoc and thus may vary between VM implementations (or even in the same VM). The issue has affected HotSpot Server VM in nightlies, and the Shark VM. As OpenJDK library code may receive broader adoption in the future, this issue may affect other VM implementations in the future as well. (Details: The HotSpot Server Compiler may recompile hot throw sites to throw a preallocated exception object, with null exception message, leading to a NPE in the test; The bytecode interpreter in Zero/Shark VM throws the ArithmeticException with / by long zero for ldiv, which is different from normal HotSpot behavior (which is expected by the test) where the exception message is / by zero.) This change relaxes the test so that it's more lenient and less sensitive to the error message produced by the VM. I don't think there's a good/reliable way of verifying whether an ArithmeticException came from division by zero, checking the type should be enough for now. Tested with the failing nightly test case and jprt. $ java -Xcomp -showversion -XX:DefaultMaxRAMFraction=8 -XX:-TieredCompilation -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:+IgnoreUnrecognizedVMOptions -XX:+AggressiveOpts -XX:+IgnoreUnrecognizedVMOptions -XX:-UseCompressedOops DivModTests java version 1.8.0-ea Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b11-internal-fastdebug, compiled mode) Exception in thread main java.lang.NullPointerException at DivModTests.resultEquals(DivModTests.java:390) at DivModTests.testIntFloorMod(DivModTests.java:126) at DivModTests.testIntFloorDivMod(DivModTests.java:103) at DivModTests.testIntFloorDivMod(DivModTests.java:68) at DivModTests.main(DivModTests.java:45) Description from the bug report: ~/jdk/test/java/lang/Math$ java -Xint -showversion DivModTests java version 1.8.0-ea Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) OpenJDK 64-Bit Shark VM (build 25.0-b11-internal, interpreted mode) FAIL: long Math.floorDiv(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero FAIL: long StrictMath.floorDiv(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero FAIL: long Math.floorMod(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero FAIL: long StrictMath.floorMod(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero Exception in thread main java.lang.RuntimeException: 4 errors found in DivMod methods. at DivModTests.main(DivModTests.java:49) Regards, Kris [1]: https://jbs.oracle.com/bugs/browse/JDK-6282196
Re: Review Request: 8004201: add reducers to primitive type wrappers
Hi Vitaly, Right now HotSpot only declares and implements the (int,int)-int version of Math.min/max as intrinsics. Nevertheless, it wouldn't hurt to use the Math methods, in hope that they'll get more love in the future :-) - Kris On 12/01/2012 02:59 AM, Vitaly Davidovich wrote: Hi Akhil, At least for Integer.min/max you may want to use Math.min/max - these are jit intrinsics. I'd probably use the Math methods for all matching types (int, long, float, double) to cover the bases. Thanks Sent from my phone On Nov 30, 2012 1:45 PM, Akhil Arora akhil.ar...@oracle.com wrote: Hi Requesting review for some basic functionality related to lambdas - Add min, max, sum methods to the primitive wrapper classes - Byte, Short, Integer, Long, Float, Double and Character so as to be able to use them as reducers in lambda expressions. Add and, or, xor methods to Boolean. http://cr.openjdk.java.net/~**akhil/8004201.0/webrev/http://cr.openjdk.java.net/~akhil/8004201.0/webrev/ http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8004201http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201 Thanks
Re: Review Request: 8004201: add reducers to primitive type wrappers
Yup, exactly. I specifically called out the int version as the one to at least change over to Math since I know that's intrinsified. Thanks Kris Sent from my phone On Nov 30, 2012 2:19 PM, Krystal Mo krystal...@oracle.com wrote: Hi Vitaly, Right now HotSpot only declares and implements the (int,int)-int version of Math.min/max as intrinsics. Nevertheless, it wouldn't hurt to use the Math methods, in hope that they'll get more love in the future :-) - Kris On 12/01/2012 02:59 AM, Vitaly Davidovich wrote: Hi Akhil, At least for Integer.min/max you may want to use Math.min/max - these are jit intrinsics. I'd probably use the Math methods for all matching types (int, long, float, double) to cover the bases. Thanks Sent from my phone On Nov 30, 2012 1:45 PM, Akhil Arora akhil.ar...@oracle.com wrote: Hi Requesting review for some basic functionality related to lambdas - Add min, max, sum methods to the primitive wrapper classes - Byte, Short, Integer, Long, Float, Double and Character so as to be able to use them as reducers in lambda expressions. Add and, or, xor methods to Boolean. http://cr.openjdk.java.net/~akhil/8004201.0/webrev/http://cr.openjdk.java.net/~**akhil/8004201.0/webrev/ http:/**/cr.openjdk.java.net/~akhil/**8004201.0/webrev/http://cr.openjdk.java.net/~akhil/8004201.0/webrev/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8004201 http://bugs.sun.**com/bugdatabase/view_bug.do?**bug_id=8004201http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201 Thanks
Re: Request for review (XXS): JDK-8004066: TEST_BUG: test/java/lang/Math/DivModTests.java assumes ArithmeticException message
The open bug URL is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004066 Sorry for the noise. - Kris On 12/01/2012 02:56 AM, Krystal Mo wrote: Forgot to mention: the two runs of the test in the last mail were examples of test failures before the fix. They would run fine after the fix. - Kris On 12/01/2012 02:48 AM, Krystal Mo wrote: Hi all, Could I get a couple of review for this small change, please? And could someone from the JDK side sponsor this change? Bug: https://jbs.oracle.com/bugs/browse/JDK-8004066 Webrev: http://cr.openjdk.java.net/~kmo/8004066/webrev.00/ The DivModTest introduced in JDK-6282196 [1] checks the contents of the exception message, but that message isn't specified in JavaDoc and thus may vary between VM implementations (or even in the same VM). The issue has affected HotSpot Server VM in nightlies, and the Shark VM. As OpenJDK library code may receive broader adoption in the future, this issue may affect other VM implementations in the future as well. (Details: The HotSpot Server Compiler may recompile hot throw sites to throw a preallocated exception object, with null exception message, leading to a NPE in the test; The bytecode interpreter in Zero/Shark VM throws the ArithmeticException with / by long zero for ldiv, which is different from normal HotSpot behavior (which is expected by the test) where the exception message is / by zero.) This change relaxes the test so that it's more lenient and less sensitive to the error message produced by the VM. I don't think there's a good/reliable way of verifying whether an ArithmeticException came from division by zero, checking the type should be enough for now. Tested with the failing nightly test case and jprt. $ java -Xcomp -showversion -XX:DefaultMaxRAMFraction=8 -XX:-TieredCompilation -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:+IgnoreUnrecognizedVMOptions -XX:+AggressiveOpts -XX:+IgnoreUnrecognizedVMOptions -XX:-UseCompressedOops DivModTests java version 1.8.0-ea Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b11-internal-fastdebug, compiled mode) Exception in thread main java.lang.NullPointerException at DivModTests.resultEquals(DivModTests.java:390) at DivModTests.testIntFloorMod(DivModTests.java:126) at DivModTests.testIntFloorDivMod(DivModTests.java:103) at DivModTests.testIntFloorDivMod(DivModTests.java:68) at DivModTests.main(DivModTests.java:45) Description from the bug report: ~/jdk/test/java/lang/Math$ java -Xint -showversion DivModTests java version 1.8.0-ea Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) OpenJDK 64-Bit Shark VM (build 25.0-b11-internal, interpreted mode) FAIL: long Math.floorDiv(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero FAIL: long StrictMath.floorDiv(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero FAIL: long Math.floorMod(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero FAIL: long StrictMath.floorMod(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero Exception in thread main java.lang.RuntimeException: 4 errors found in DivMod methods. at DivModTests.main(DivModTests.java:49) Regards, Kris [1]: https://jbs.oracle.com/bugs/browse/JDK-6282196
hg: jdk8/tl/jdk: 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by couldn't get file lock
Changeset: 43d2e02c4098 Author:khazra Date: 2012-11-30 12:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43d2e02c4098 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by couldn't get file lock Summary: Set -Djava.util.prefs.userRoot to current working directory of user in the prefs tests Reviewed-by: alanb, chegar, weijun, dxu ! test/java/util/prefs/AddNodeChangeListener.java ! test/java/util/prefs/CheckUserPrefsStorage.sh ! test/java/util/prefs/CommentsInXml.java ! test/java/util/prefs/ConflictInFlush.java ! test/java/util/prefs/ExportNode.java ! test/java/util/prefs/ExportSubtree.java ! test/java/util/prefs/PrefsSpi.sh ! test/java/util/prefs/RemoveNullKeyCheck.java ! test/java/util/prefs/RemoveReadOnlyNode.java ! test/java/util/prefs/RemoveUnregedListener.java
Request for review for [JBS] (JDK-8004212) java.util.Base64 methods decodeArray and decodeBuffer should return the number of bytes written
Alan, It appears the return value is not correct in decode(Bytebuffer...) case if the buffer is overflow. Here is the webrev for that. http://cr.openjdk.java.net/~sherman/8004212/webrev/ Thanks, -Sherman
Re: Review/comment needed for the new public java.util.Base64 class
Hi Sherman,
is this ssue still open ?
-Ulf
Am 03.11.2012 21:33, schrieb Ulf Zibis:
Am 30.10.2012 23:40, schrieb Xueming Shen:
I'm confused about the order of xxcode() and Xxcoder.
In other places e.g. charsets, we have de... before en..., which is also true
alphabetical
should not be an issue. javadoc output should be in alphabetic order. If it is
really
concerns you, I can do a copy/paste:-)
Yes, it doesn't matter much, but would be a nice conform style, so for me personally I would
like the copy/paste:-)
- What (should) happen(s), if lineSeparator.length == 0 ?
do nothing. expected?
I would say, empty line separator should not be allowed, so you might check:
Objects.requireNonEmpty(lineSeparator);
603 static {
604 Arrays.fill(fromBase64, -1);
605 for (int i = 0; i Encoder.toBase64.length; i++)
606 fromBase64[Encoder.toBase64[i]] = i;
607 fromBase64['='] = -2;
608 }
This causes the inner Encoder class to be loaded, even if not needed. So maybe move the toBase64
table to the outer class.
Have you compared performance with fromBase64 as byte[] (including local 'b' in
decode() as byte)?
understood.
It seems you have mixed 2 tweaks to one. ;-) See additional paragraph at the
end ...
but it appears the hotspot likes it the constant/fixed length lookup
table is inside encoder.
Yes, but see my suggestion 12 lines below.
Same as you suggestion in your previous email to use
String in source and expand it during runtime. It saves about 500 bytes but
slows
the server vm.
Are you really sure? As it only runs once at class init, JIT should not compile
this code.
Executing the bytecode to init the final int[], value for value, by interpreter should not be
faster as expanding a String source in a loop.
Those repeating lines of isURL? is also supposed to be a
performance tweak to eliminate the array boundary check in loop.
Yep, so I was thinking about:
653 private final int[] base64;
654 private final boolean isMIME;
655
656 private Decoder(boolean isURL, boolean isMIME) {
657 base64 = isURL ? fromBase64URL : fromBase64;
658 this.isMIME = isMIME;
659 }
.
911 private int decodeBuffer(ByteBuffer src, ByteBuffer dst) {
912 int[] base64 = this.base64; // local copy for performance reasons (but maybe
superfluous if HotSpot is intelligent enough)
or:
911 private int decodeBuffer(ByteBuffer src, ByteBuffer dst, int[]
base64) {
.
Why you mix the algorithms to check the padding? :
824 if (b == -2) { // padding byte
890 if (b == '=') {
It is supposed reduce one if check for normal base64 character inside the
loop. I'm not that sure it really helps though.
925 if (b == '=') {
-- causes one additional if in the _main_ path of the loop, so should be
slower for regular input
859 if (b == -2) { // padding byte
-- causes one additional if in the _side_ path of the loop, so should only
affect irregular input
Maybe the following code is little faster as no loading of the constant '-2' is
required:
858 if ((b = base64[b]) 0) {
859 if (++b 0) { // padding byte '='
Once again (the following was meant for the decode algorithm, not
initialisation):
Have you compared performance with fromBase64 as byte[] (including local 'b' in
decode() as byte)?
Retrieving the bytes by b = base64[x] then could be done without address-shift and smaller/faster
LoadB operations could be used by JIT. In an int[] table, the index offset must be shifted by 2
before. Maybe this doesn't directly affect the performance on x86/IA64 CPU, but wastes space in
CPU cache for other tasks as a side effect. On ARM architectures I imagine, directly addressing a
byte-stepped table could be faster than addressing a 4-byte-stepped table. At least the footprint
of the table would be smaller.
Little nit:
You could delete line 641 for conformity with 629.
-Ulf
Re: Request for Review (#4) : CR#8001634 : Initial set of lambda functional interfaces
Couple of quick comments:
1. I think the naming is inconsistent between class and method, e.g.
IntFunction has an applyAsInt method. Why not either IntFunction and intApply
or FunctionAsInt and applyAsInt?
2. It would be good to have a description of the stream library, perhaps an
expanded for of Brian's State of Streams document referenced throughout the API
like the Collections API has.
Sent from my iPad
On 20/11/2012, at 5:31 PM, David Holmes david.hol...@oracle.com wrote:
Hi Mike,
Minor typos and inconsistencies:
DoubleBinaryOperator.java
28 * Combines two {@code double} operands producing an {@code double}
result.
an - a
51 * @param rightvalue used as the right operand
Need space after right
52 * @return result value of the operation
result value doesn't read right - just @return the result of ... -
as for BinaryOperator.operate
General consistency: all like methods in a family of interfaces should
use the same wording. Eg BinaryOperator.operate says upon the provided
operands whereas DoubleBinaryOperator.* says upon the operands. Ditto
across families ie UnaryOperator and BinaryOperator should use
consistent terminology for operands and results.
---
DoubleBlock.java:
31 * @param T The type of input objects to {@code accept}.
DoubleBlock is not a generic type. (Surely this should be generating a
javadoc warning?)
---
DoubleFunction.java
32 * @param T the type of input objects to the {@code apply} operation.
You now potentially have multiple operation methods, and T refers to the
input of all of them.
General consistency comments across everything:
- Use of operand versus provided operand versus input value etc
- Use of result vs computed result vs result value vs output etc
---
Function.java
33 * @param R the type of output objects from {@code apply} operation.
from - from the
43 * @param t the input object to be to which the function will
be applied.
delete to be ? Or else re-word.
---
UnaryOperator.java
28 * Operator on a single operand.
Operator - operate ?
30 * @param T the type of input objects to {@code operate} and of
the result.
objects - object
---
Cheers,
David
On 20/11/2012 2:55 PM, Mike Duigou wrote:
I have posted another revision at
http://cr.openjdk.java.net/~mduigou/8001634/5/webrev/
This version contains some method remaining in the {I|L|D}UnaryOperation and
{I|L|D}BinaryOperator and a few Javadoc fixes.
The package javadoc ie. package-info.java, is known to be a weak point right
now. We're still debating what must be said here and what would be better
said attached to the APIs which consume these functional interfaces.
We don't anticipate many (any?) further changes to the naming before commit
at this point.
Mike
On Nov 13 2012, at 17:19 , Mike Duigou wrote:
Hello all;
I apologize for the quick turnaround from the second review request [1] but
I've updated the webrev again:
http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/
Blame a busy Paul Sandoz who his making significant progress on the
primitive specializations implementation. ;-)
This update includes:
- Block.apply renamed to Block.accept
- {Int|Long|Double}Block specializations added.
- Commented out extends CombinerT,T,T in BinaryOperator was removed for
now since Combiner is out of scope for this review.
- The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator
now show commented out extends of the generic version along with commented
out default methods. This change will not be part of the commit but is
meant to show where the implementation will be going.
- The {Int|Long|Double} specializations of Supplier now extend generic
Supplier, have getAs{Int|Long|Double} as their abstract method and provide
a commented out default get() method to satisfy the need for a get
implementation.
- The {Int|Long|Double} specializations of Function now extend generic
Function, have applyAs{Int|Long|Double} as their abstract method and
provide a commented out default apply() method to satisfy the need for an
apply implementation.
Mike
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
What is the benefit of throwing an IllegalStateException in a default method over not providing any default method so that the compiler and runtime make sure concrete subtypes provide an implementation? On Nov 30, 2012 9:54 AM, Lance Andersen - Oracle lance.ander...@oracle.com wrote: On Nov 30, 2012, at 4:58 AM, Chris Hegarty wrote: On 30/11/2012 02:03, David Holmes wrote: On 30/11/2012 12:44 AM, Chris Hegarty wrote: On 11/29/2012 05:50 AM, David Holmes wrote: ... I don't agree that we need to describe what the default implementation does, for two reasons: 1. Normal methods don't usually specify how they are implemented - it is an implementation detail. The default simply indicates that this method does have an implementation and you should expect that implementation to obey the contract of the method. 2. It is not obvious to me that the JDK's choice for a default implementation has to be _the_ only possible implementation choice. In many/most cases there will be a very obvious choice, but that doesn't mean that all suppliers of OpenJDK classes have to be locked in to that choice. This is certainly interesting, and something I've wondered for a while now. If java.util.Iterator is to ever be fitted with a default implementation of remove ( to throw UnsupportedOperationException ), then it would clearly need to be part of the spec, and not an implementation detail of OpenJDK. Otherwise, what's the point, every developer will still have to implement it because they cannot be guaranteed of it's behavior. I think optional methods are a bit of a special case here because they don't have to work. It's the end user of a class that needs to understand if they can use remove() to actually do a removal. The developer of the class can inherit whatever default implementations Iterator provides, as long as they don't mind what they get. If they do mind ie they need a real remove(), then they will have to implement it themselves and in the process document that fact. The end user has to look at the docs for the concrete class and follow through to determine whether it's iterator().remove() is optional or not. Put another way, a default method is great for adding a new method to types that have not yet been revised to handle the new method. As a developer once you revise your class you should make a conscious implementation choice in my opinion and not rely on the default unless you truly don't care what it does. Sorry David, I've not been following lambda that closely, but (in my opinion) if default methods do not, or cannot, have defined semantics then I really think it is limiting. Maybe Iterator is a bad example, but I will continue with it anyway. In many cases developers of iterator().remove() want it to throw, if this is not defined in Iterator's default remove method then every Iterator subclass will still have to define its own remove that throws. For this particular case at least (if it were to ever happen), I would like to see specification added to remove that defines the default implementation. I had wondered about this as well and had a brief email exchange with Mike. I thought a new javadoc tag might also be something to consider. For JDBC, I am thinking of leveraging default methods to throw a specific exception (maybe IllegalStateException?) if the method must be implemented by the driver vendor or a SQLFeatureNotSupportedException for methods which may be optional based on the backend support. -Chris. But maybe we kid ourselves when we give this illusion of flexibility in implementation. David -Chris. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
RFR- 7200297 jdwp and hprof code do not handle multiple sun.boot.library.path elements correctly
This bug was reviewed by serviceability and hotspot-runtime-dev lists since it dealt with jvmti agent code. Comments welcome. The intent is to push into tl/jdk tree and then eventually back into jdk7u-dev hopefully. Webrev here: http://cr.openjdk.java.net/~bpittore/7200297/webrev.04/ And previous reviews here: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-November/004801.html thanks, bill
hg: jdk8/tl/jdk: 7198904: (alt-rt) TreeMap.clone is broken
Changeset: f389bf27fc4f Author:dbuck Date: 2012-11-20 21:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f389bf27fc4f 7198904: (alt-rt) TreeMap.clone is broken Summary: Test case for cr7198904. Issue only found in OracleJDK, but test case is valid for OpenJDK as well Reviewed-by: mduigou, dholmes + test/java/util/TreeMap/Clone.java
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
On Thu, Nov 29, 2012 at 6:50 PM, David Holmes david.hol...@oracle.comwrote:
Mike,
On 28/11/2012 3:32 AM, Mike Duigou wrote:
On Nov 27 2012, at 03:56 , Stephen Colebourne wrote:
On 27 November 2012 02:12, Mike Duigoumike.dui...@oracle.com wrote:
In the original patch which added the basic lambda functional
interfaces, CR#8001634 [1], none of the interfaces extended other
interfaces. The reason was primarily that the javac compiler did not, at
the time that 8001634 was proposed, support extension methods. The compiler
now supports adding of method defaults so this patch improves the
functional interfaces by filing in the inheritance hierarchy.
Adding the parent interfaces and default methods allows each
functional interface to be used in more places. It is especially important
for the functional interfaces which support primitive types, IntSupplier,
IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that
eventually standard implementations of these interfaces will be provided
for functions like max, min, sum, etc. By extending the reference oriented
functional interfaces such as Function, the primitive implementations can
be used with the boxed primitive types along with the primitive types for
which they are defined.
The patch to add parent interfaces and default methods can be found
here:
http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/
http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html
Each of the default methods is formatted on a single line. I consider
this to be bad style, they should be formatted as per normal
methods:
@Override
public default Double operate(Double left, Double right) {
return operateAsDouble((double) left, (double) right);
}
It is vitally important to get this kind of formatting/style correct.
Developers the world over will be copying what the style is in these
classes.
I totally agree that we should be consistent but I don't believe that
there's a consensus yet on what good style is for these cases. What's your
rationale for it being bad style?
I have to concur with Stephen - these are just method definitions and
should follow the same style that is used for method definitions in
classes. No need to contemplate introducing a new style just for default
methods.
I've personally never a one-style-to-rule-them-all kinda guy and I usual
format trivial methods this way - that is, trivial getters, setters and
delegating implementations.
I've considered the vertical brevity a readability benefit in these cases
and the absence of 'abstract' (for class methods) or the presence of
default (for interfaces) seems cue enough.
Still, at least it's not the opposite extreme.
While I'm happy with (though 2-space vs 4-space indentations are my
preference)...
@Override
public default Double operate(Double left, Double right) { return
operateAsDouble((double) left, (double) right); }
I've worked with those that think this is necessary (assume a fixed width
font to understand the indentation)...
@Override
public default Double operate(
Double left,
Double right
)
{
return operateAsDouble( ( double ) left, ( double ) right );
}
Monitor aspects are getting relatively wider and screens larger overall.
IMO longer lines and fewer content-less lines simply fits the medium better.
There is also no Javadoc on the default method override.
That was intentional. The goal was to inherit from the original
definition.
I don't think we can just leave it at that. If we are introducing
additional constraints over that specified in base method then they need
to be documented. We should be able to use implicit doc inheritance plus
@{inheritDoc} to bring down what is unchanged and then add what is needed.
Agreed. Don't put superfluous {@inheritDoc} in there but please don't omit
the Javadoc entirely if the contract is further constrained.
I don't agree that we need to describe what the default implementation
does, for two reasons:
1. Normal methods don't usually specify how they are implemented - it is
an implementation detail. The default simply indicates that this
method does have an implementation and you should expect that
implementation to obey the contract of the method.
2. It is not obvious to me that the JDK's choice for a default
implementation has to be _the_ only possible implementation choice. In
many/most cases there will be a very obvious choice, but that doesn't
mean that all suppliers of OpenJDK classes have to be locked in to that
choice.
I have a dilemma, I disagree with the first point but not the second.
Describing the complexity of the algorithm selected by default is useful
information - It's saying how it scales, not how it's implemented.
Documentation on how methods scale in a library is
Re: Review/comment needed for the new public java.util.Base64 class
Ulf,
The base64 implementation is in TL right now. It does address some of the
issue you suggested in this email. And I remember I did try use byte[]
alphabets, which I don't recall bring us any benefit, but I'm not sure in which
setup. The latest is at
http://cr.openjdk.java.net/~sherman/8004212/webrev/
in which I'm trying to fix a corner case of incorrect return value from
decode(buf, buf).
The Base64 now is in TL does not necessary mean the issue is closed. You
can continue suggest/comment on the latest version for any possible performance
improvement, bug fix and even API change, if necessary.
-Sherman
On 11/30/2012 02:01 PM, Ulf Zibis wrote:
Hi Sherman,
is this ssue still open ?
-Ulf
Am 03.11.2012 21:33, schrieb Ulf Zibis:
Am 30.10.2012 23:40, schrieb Xueming Shen:
I'm confused about the order of xxcode() and Xxcoder.
In other places e.g. charsets, we have de... before en..., which is also true
alphabetical
should not be an issue. javadoc output should be in alphabetic order. If it is
really
concerns you, I can do a copy/paste:-)
Yes, it doesn't matter much, but would be a nice conform style, so for me
personally I would like the copy/paste:-)
- What (should) happen(s), if lineSeparator.length == 0 ?
do nothing. expected?
I would say, empty line separator should not be allowed, so you might check:
Objects.requireNonEmpty(lineSeparator);
603 static {
604 Arrays.fill(fromBase64, -1);
605 for (int i = 0; i Encoder.toBase64.length; i++)
606 fromBase64[Encoder.toBase64[i]] = i;
607 fromBase64['='] = -2;
608 }
This causes the inner Encoder class to be loaded, even if not needed. So maybe
move the toBase64 table to the outer class.
Have you compared performance with fromBase64 as byte[] (including local 'b' in
decode() as byte)?
understood.
It seems you have mixed 2 tweaks to one. ;-) See additional paragraph at the
end ...
but it appears the hotspot likes it the constant/fixed length lookup
table is inside encoder.
Yes, but see my suggestion 12 lines below.
Same as you suggestion in your previous email to use
String in source and expand it during runtime. It saves about 500 bytes but
slows
the server vm.
Are you really sure? As it only runs once at class init, JIT should not compile
this code.
Executing the bytecode to init the final int[], value for value, by interpreter
should not be faster as expanding a String source in a loop.
Those repeating lines of isURL? is also supposed to be a
performance tweak to eliminate the array boundary check in loop.
Yep, so I was thinking about:
653 private final int[] base64;
654 private final boolean isMIME;
655
656 private Decoder(boolean isURL, boolean isMIME) {
657 base64 = isURL ? fromBase64URL : fromBase64;
658 this.isMIME = isMIME;
659 }
.
911 private int decodeBuffer(ByteBuffer src, ByteBuffer dst) {
912 int[] base64 = this.base64; // local copy for performance
reasons (but maybe superfluous if HotSpot is intelligent enough)
or:
911 private int decodeBuffer(ByteBuffer src, ByteBuffer dst, int[]
base64) {
.
Why you mix the algorithms to check the padding? :
824 if (b == -2) { // padding byte
890 if (b == '=') {
It is supposed reduce one if check for normal base64 character inside the
loop. I'm not that sure it really helps though.
925 if (b == '=') {
-- causes one additional if in the _main_ path of the loop, so should be
slower for regular input
859 if (b == -2) { // padding byte
-- causes one additional if in the _side_ path of the loop, so should only
affect irregular input
Maybe the following code is little faster as no loading of the constant '-2' is
required:
858 if ((b = base64[b]) 0) {
859 if (++b 0) { // padding byte '='
Once again (the following was meant for the decode algorithm, not
initialisation):
Have you compared performance with fromBase64 as byte[] (including local 'b' in
decode() as byte)?
Retrieving the bytes by b = base64[x] then could be done without address-shift
and smaller/faster LoadB operations could be used by JIT. In an int[] table,
the index offset must be shifted by 2 before. Maybe this doesn't directly
affect the performance on x86/IA64 CPU, but wastes space in CPU cache for other
tasks as a side effect. On ARM architectures I imagine, directly addressing a
byte-stepped table could be faster than addressing a 4-byte-stepped table. At
least the footprint of the table would be smaller.
Little nit:
You could delete line 641 for conformity with 629.
-Ulf
RFR: 8003596 CheckLockLocationTest-Windows-fix
Please review http://cr.openjdk.java.net/~jgish/Bug8003596-CheckLockLocationTest-Windows-fix/ http://cr.openjdk.java.net/%7Ejgish/Bug8003596-CheckLockLocationTest-Windows-fix/ Summary: fixes test when running on Windows so that test that requires setWritable is not run, because Windows does not support setWritable. Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.g...@oracle.com
hg: jdk8/tl/jaxp: 2 new changesets
Changeset: e6af1ad464e3 Author:katleman Date: 2012-11-15 15:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/e6af1ad464e3 Added tag jdk8-b65 for changeset 5cf3c69a93d6 ! .hgtags Changeset: 83df3493ca3c Author:katleman Date: 2012-11-29 11:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/83df3493ca3c Added tag jdk8-b66 for changeset e6af1ad464e3 ! .hgtags
hg: jdk8/tl: 14 new changesets
Changeset: 0e1b5886b06c Author:katleman Date: 2012-11-15 15:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0e1b5886b06c Added tag jdk8-b65 for changeset b772de306dc2 ! .hgtags Changeset: a2df4ee40ecb Author:tbell Date: 2012-11-14 10:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a2df4ee40ecb 8002026: build-infra: deploy repository building Summary: Change the compare script to handle deploy build artifacts. Reviewed-by: ohair, tbell Contributed-by: erik.joels...@oracle.com ! common/bin/compare.sh ! common/bin/compare_exceptions.sh.incl Changeset: c81c4a5d8b50 Author:tbell Date: 2012-11-14 10:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c81c4a5d8b50 8001875: build-infra: We must be able to force static linking of stdc++ Summary: Ensure that we build with static linking when requested, or do not build at all Reviewed-by: ohair, tbell Contributed-by: erik.joels...@oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: 582c696033f5 Author:tbell Date: 2012-11-14 10:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/582c696033f5 8001941: build-infra: --disable-precompiled-headers does not seem to work Summary: With this fix the flag will do what it advertises Reviewed-by: ohair, tbell Contributed-by: erik.joels...@oracle.com ! common/autoconf/build-performance.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in Changeset: f59a07f85125 Author:tbell Date: 2012-11-14 10:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f59a07f85125 8003317: build-infra: Configure fails when current dir is part of a symlink Summary: Call macro for removing symbolic links on a copy of the CURDIR variable before comparing Reviewed-by: ohair, tbell Contributed-by: erik.joels...@oracle.com ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: e69396d6d3e8 Author:tbell Date: 2012-11-14 10:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e69396d6d3e8 8003327: build-infra: /bin/sh: : cannot execute on solaris Summary: Fix quoting inside cut command used in the pipeline Reviewed-by: ohair, tbell Contributed-by: erik.joels...@oracle.com ! common/makefiles/MakeHelpers.gmk Changeset: 06f146c05f49 Author:tbell Date: 2012-11-15 00:54 + URL: http://hg.openjdk.java.net/jdk8/tl/rev/06f146c05f49 Merge Changeset: ecf751a69f6a Author:tbell Date: 2012-11-19 14:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ecf751a69f6a 8003300: build-infra: fails on solaris when objcopy is not found Summary: Only call BASIC_FIXUP_EXECUTABLE() if objcopy was found. Reviewed-by: tbell Contributed-by: erik.joels...@oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: f8b0bacd4de5 Author:erikj Date: 2012-11-28 13:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f8b0bacd4de5 8001460: build-infra: Linker warnings on macosx Summary: Only linking against jvm variant specific dirs if they are expected to exist. Reviewed-by: ohair ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: 6ff2e1280dc3 Author:erikj Date: 2012-11-28 13:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6ff2e1280dc3 8003844: build-infra: docs target isn't working properly Summary: Fixed docs and docs-clean target. Added compare support for docs. Reviewed-by: ohair, jjg, ohrstrom ! common/bin/compare.sh ! common/makefiles/Main.gmk ! common/makefiles/javadoc/Javadoc.gmk Changeset: 7d7dd520ebfd Author:erikj Date: 2012-11-28 13:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7d7dd520ebfd 8003528: build-infra: Diffs in libjava and hotspot libs on solaris. Summary: Linking against server jvm first if available. Adding filters and exceptions for hotspot lib compare on solaris. Reviewed-by: ohair, ohrstrom ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 ! common/bin/compare_exceptions.sh.incl Changeset: 13bb8c326e7b Author:katleman Date: 2012-11-28 14:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/13bb8c326e7b Merge Changeset: 16292f54195c Author:katleman Date: 2012-11-29 11:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/16292f54195c Added tag jdk8-b66 for changeset 13bb8c326e7b ! .hgtags Changeset: ad54163c95f5 Author:lana Date: 2012-11-30 16:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ad54163c95f5 Merge
hg: jdk8/tl/corba: 2 new changesets
Changeset: 65771ad1ca55 Author:katleman Date: 2012-11-15 15:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/65771ad1ca55 Added tag jdk8-b65 for changeset 5132f7900a8f ! .hgtags Changeset: 394515ad2a55 Author:katleman Date: 2012-11-29 11:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/394515ad2a55 Added tag jdk8-b66 for changeset 65771ad1ca55 ! .hgtags
hg: jdk8/tl/langtools: 6 new changesets
Changeset: b5d326a809a1 Author:katleman Date: 2012-11-15 15:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b5d326a809a1 Added tag jdk8-b65 for changeset 5f2faba89cac ! .hgtags Changeset: 09ba1bfab344 Author:lana Date: 2012-11-20 11:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/09ba1bfab344 Merge - src/share/classes/com/sun/tools/javac/parser/SimpleDocCommentTable.java - test/tools/javac/defaultMethods/fd/FDTest.java - test/tools/javac/defaultMethods/fd/shapegen/ClassCase.java - test/tools/javac/defaultMethods/fd/shapegen/Hierarchy.java - test/tools/javac/defaultMethods/fd/shapegen/HierarchyGenerator.java - test/tools/javac/defaultMethods/fd/shapegen/Rule.java - test/tools/javac/defaultMethods/fd/shapegen/RuleGroup.java - test/tools/javac/defaultMethods/fd/shapegen/TTNode.java - test/tools/javac/defaultMethods/fd/shapegen/TTParser.java - test/tools/javac/defaultMethods/fd/shapegen/TTShape.java - test/tools/javac/diags/examples/CantAccessArgTypeInFunctionalDesc.java - test/tools/javac/diags/examples/CantAccessReturnTypeInFunctionalDesc.java - test/tools/javac/diags/examples/CantAccessThrownTypesInFunctionalDesc.java - test/tools/javac/diags/examples/CantReturnValueForVoid.java Changeset: da48ab364ea4 Author:erikj Date: 2012-11-28 13:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/da48ab364ea4 8003844: build-infra: docs target isn't working properly Summary: Adding resources to bootstrap javadoc.jar. Adding missing .js resource suffix Reviewed-by: ohair, jjg, ohrstrom ! makefiles/BuildLangtools.gmk Changeset: 20230f8b0eef Author:katleman Date: 2012-11-28 14:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/20230f8b0eef Merge Changeset: 303b09787a69 Author:katleman Date: 2012-11-29 11:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/303b09787a69 Added tag jdk8-b66 for changeset 20230f8b0eef ! .hgtags Changeset: 98e14fc9ee11 Author:lana Date: 2012-11-30 16:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/98e14fc9ee11 Merge
hg: jdk8/tl/jdk: 18 new changesets
Changeset: c87df8b1f55e Author:katleman Date: 2012-11-15 15:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c87df8b1f55e Added tag jdk8-b65 for changeset 130d3a54d28b ! .hgtags Changeset: 03d22c98b30a Author:ceisserer Date: 2012-11-13 16:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/03d22c98b30a 7105461: Large JTables are not rendered correctly with Xrender pipeline Reviewed-by: flar, prr ! src/solaris/classes/sun/java2d/xr/XRRenderer.java ! src/solaris/classes/sun/java2d/xr/XRUtils.java Changeset: ed977ca9a969 Author:lana Date: 2012-11-20 11:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ed977ca9a969 Merge Changeset: 11ba8795bbe9 Author:kshefov Date: 2012-11-14 11:37 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11ba8795bbe9 7147408: [macosx] Add autodelay to fix a regression test Reviewed-by: serb, alexsch + test/javax/swing/text/StyledEditorKit/4506788/bug4506788.html + test/javax/swing/text/StyledEditorKit/4506788/bug4506788.java Changeset: f32a0aee7bb9 Author:alitvinov Date: 2012-11-14 18:40 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f32a0aee7bb9 6789984: JPasswordField can not receive keyboard input Reviewed-by: naoto, anthony ! src/share/classes/sun/awt/im/InputContext.java ! src/share/classes/sun/awt/im/InputMethodAdapter.java ! src/solaris/classes/sun/awt/X11InputMethod.java Changeset: 0269459afe2a Author:malenkov Date: 2012-11-20 18:56 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0269459afe2a 800: Regression: java/beans/EventHandler/Test6277266.java fails with ACE Reviewed-by: art ! test/java/beans/EventHandler/Test6277266.java Changeset: ea368459cca5 Author:lana Date: 2012-11-20 11:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ea368459cca5 Merge Changeset: 107a7a52a3c0 Author:lana Date: 2012-11-20 11:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/107a7a52a3c0 Merge Changeset: ccff3b663797 Author:tbell Date: 2012-11-14 10:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ccff3b663797 8001906: build-infra: warning: [path] bad path element on Solaris Summary: Remove unnecesary -cp parameter from compile line Reviewed-by: ohair, tbell Contributed-by: erik.joels...@oracle.com ! makefiles/CompileDemos.gmk Changeset: 716efc201640 Author:tbell Date: 2012-11-15 00:55 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/716efc201640 Merge Changeset: 44e845bb5f76 Author:erikj Date: 2012-11-28 09:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44e845bb5f76 8003960: build-infra: Jarsigner launcher has wrong classname Summary: Fixed package name in launcher Reviewed-by: alanb, ohair, ohrstrom ! makefiles/CompileLaunchers.gmk Changeset: ad5741112252 Author:erikj Date: 2012-11-28 13:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad5741112252 8001460: build-infra: Linker warnings on macosx Summary: Remove creation of empty i386 section from fdlibm Reviewed-by: ohair ! makefiles/CompileNativeLibraries.gmk Changeset: 7ecc80d2ff2e Author:erikj Date: 2012-11-28 13:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ecc80d2ff2e 8003477: build-infra: Remove explicit source file listings for libs when possible Reviewed-by: ohair, ohrstrom ! makefiles/CompileNativeLibraries.gmk Changeset: 51d2fd6d9850 Author:erikj Date: 2012-11-28 13:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51d2fd6d9850 8003528: build-infra: Diffs in libjava and hotspot libs on solaris. Summary: Reorder libraries on link command line to match old build. Reviewed-by: ohair, ohrstrom ! makefiles/CompileNativeLibraries.gmk Changeset: 54516ed0f99f Author:erikj Date: 2012-11-28 14:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/54516ed0f99f 8003482: build-infra: Use correct manifest in security jars Reviewed-by: ohair, ohrstrom ! makefiles/CreateJars.gmk Changeset: 4d337fae2250 Author:katleman Date: 2012-11-28 14:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d337fae2250 Merge Changeset: df5619994dc3 Author:katleman Date: 2012-11-29 11:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df5619994dc3 Added tag jdk8-b66 for changeset 4d337fae2250 ! .hgtags Changeset: e66ec5b8c15e Author:lana Date: 2012-11-30 16:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e66ec5b8c15e Merge
hg: jdk8/tl/hotspot: 25 new changesets
Changeset: 4e3e685dbc9d Author:katleman Date: 2012-11-15 15:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4e3e685dbc9d Added tag jdk8-b65 for changeset 0f7290a03b24 ! .hgtags Changeset: 3be318ecfae5 Author:amurillo Date: 2012-11-09 08:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3be318ecfae5 8003231: new hotspot build - hs25-b10 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 6cb0d32b828b Author:bpittore Date: 2012-11-07 17:53 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6cb0d32b828b 8001185: parsing of sun.boot.library.path in os::dll_build_name somewhat broken Summary: dll_dir can contain multiple paths, need to parse them correctly when loading agents Reviewed-by: dholmes, dlong Contributed-by: bill.pitt...@oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp Changeset: d9a84e246cce Author:cjplummer Date: 2012-11-09 09:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d9a84e246cce Merge ! src/share/vm/runtime/thread.cpp Changeset: 429994fc0754 Author:cjplummer Date: 2012-11-14 10:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/429994fc0754 Merge Changeset: 6bc207d87e5d Author:mgerdin Date: 2012-11-09 00:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6bc207d87e5d 7200229: NPG: possible performance issue exposed by closed/runtime/6559877/Test6559877.java Summary: Reduce the amount of calls to ChunkManager verification code Reviewed-by: jmasa, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp Changeset: 0400886d2613 Author:coleenp Date: 2012-11-14 22:37 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0400886d2613 8003259: NPG: Build with gcc 4.7.2 broken by 7045397 Summary: Qualify calls with this pointers to make gcc accept this code. Reviewed-by: coleenp, andrew Contributed-by: peter.lev...@gmail.com ! src/share/vm/memory/binaryTreeDictionary.cpp Changeset: c5d4acbb943d Author:johnc Date: 2012-11-15 14:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c5d4acbb943d Merge Changeset: bd7a7ce2e264 Author:minqi Date: 2012-11-12 14:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bd7a7ce2e264 6830717: replay of compilations would help with debugging Summary: When java process crashed in compiler thread, repeat the compilation process will help finding root cause. This is done with using SA dump application class data and replay data from core dump, then use debug version of jvm to recompile the problematic java method. Reviewed-by: kvn, twisti, sspitsyn Contributed-by: yumin...@oracle.com + agent/doc/c2replay.html ! agent/doc/clhsdb.html ! agent/doc/index.html ! agent/make/Makefile ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciBaseObject.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciConstant.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodData.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Field.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Metadata.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciMetadata.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.hpp + src/share/vm/ci/ciReplay.cpp + src/share/vm/ci/ciReplay.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/ci/ciUtilities.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/invocationCounter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/opto/bytecodeInfo.cpp !
hg: jdk8/tl/jaxws: 2 new changesets
Changeset: 3eb7f11cb4e0 Author:katleman Date: 2012-11-15 15:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/3eb7f11cb4e0 Added tag jdk8-b65 for changeset fbe54291c9d3 ! .hgtags Changeset: eb06aa51dfc2 Author:katleman Date: 2012-11-29 11:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/eb06aa51dfc2 Added tag jdk8-b66 for changeset 3eb7f11cb4e0 ! .hgtags
