Re: Proposal: Fully Concurrent ClassLoading
On Sat, Dec 15, 2012 at 3:24 AM, David Holmes david.hol...@oracle.com wrote: On 15/12/2012 12:58 AM, Zhong Yu wrote: On Wed, Dec 12, 2012 at 5:48 PM, David Holmesdavid.hol...@oracle.com wrote: On 13/12/2012 1:51 AM, Zhong Yu wrote: If a class loader is declared fully concurrent, yet getClassLoadingLock() is invoked, what's the harm of returning a dedicated lock anyway, exactly like what's done before? The whole point is to get rid of the lockMap and these lock objects. I could return a sentinel Object in all cases rather than null but that just seems to encourage continued use of something that shouldn't be used with a fully concurrent loader. Returning null versus throwing an exception is mostly a matter of style. I'd want to hear from anyone who invokes getClassLoadingLock() on any of the system classloaders to see which is preferable. Since this change will break some applications, the failure should be loud, with immediate and detailed information on what's going on, so the poor developers can fix the problem quickly. Can you suggest any actual use of the result of getClassLoadingLock() that won't cause a NullPointerException if null is returned? I'm saying a more specific exception could be more helpful than NPE, for example, UnsupportedOperationException(getClassLoadingLock() not supported in a fully concurrent class loader) I had the pleasure of implementing classloaders before, and I think it might be underestimated how many classloaders are actually out there. The question is how many of them became parallel capable in Java 7 and out of those how many actually use the lockMap (via getClassLoadingLock()) themselves? Do you have any real data on that? Can you even conceive a realistic example of how a custom loader might use the lock supplied by a parent loader? Cheers, David Zhong
Re: ReflectionData space optimization in java.lang.Class (JEP-149)
Hi David, Mandy, Joel and others, I prepared the 3rd revision of the patch: http://dl.dropbox.com/u/101777488/jdk8-tl/JEP-149.c/webrev.03/index.html Changes from the 1st revision (disregard 2nd revision) are as follows: - The split of reflectionData() method into short fast-path and longer slow-path newReflectionData() as already proposed in 2nd revision of the patch. - The logic of privateGetDeclared[Fields|Methods|Constructors](boolean publicOnly) methods has been rewritten to eliminate caching of duplicate Field/Method/Constructor instances for the same field, method or constructor. As it turns out, the same public Member can be cached twice. One instance in ReflectionData.declared[Fields|Methods|Constructors] array and the other instance in ReflectionData.declaredPublic[Fields|Methods] or publicConstructors array. These arrays pairs (declared/declaredPublic) retain distinct instances, because they are obtained by separate calls to VM which always constructs new instances. The new proposed logic eliminates duplicate instances, but does not otherwise present any new overhead. It never requests more data from VM then needed at a particular moment (it may request less data from VM if external calls are issued in a particular order). Some applications may benefit from saved allocated space if they request declared members and public members on same Class instances. Here's the comparison of bytes allocated for the ReflectionData object in some Class instances after invoking particular reflection methods: *** *** Original JDK8 privateGetDeclaredXXX methods: *** Deep size of ReflectionData in: java.lang.Object.class before any calls: 0 bytes after getDeclaredConstructors: 192 bytes after getDeclaredFields: 192 bytes after getDeclaredMethods: 1,552 bytes after getConstructors: 1,664 bytes after getFields: 1,696 bytes after getMethods: 2,856 bytes Deep size of ReflectionData in: java.lang.String.class before any calls: 704 bytes after getDeclaredConstructors: 2,472 bytes after getDeclaredFields: 2,472 bytes after getDeclaredMethods: 10,808 bytes after getConstructors: 12,464 bytes after getFields: 12,712 bytes after getMethods: 21,056 bytes Deep size of ReflectionData in: java.util.HashMap.class before any calls: 0 bytes after getDeclaredConstructors: 472 bytes after getDeclaredFields: 1,328 bytes after getDeclaredMethods: 5,856 bytes after getConstructors: 6,360 bytes after getFields: 6,392 bytes after getMethods: 9,576 bytes Deep size of ReflectionData in: javax.swing.JTable.class before any calls: 0 bytes after getDeclaredConstructors: 784 bytes after getDeclaredFields: 4,224 bytes after getDeclaredMethods: 26,072 bytes after getConstructors: 26,792 bytes after getFields: 28,600 bytes after getMethods: 79,912 bytes *** *** With modified privateGetDeclaredXXX methods: *** Deep size of ReflectionData in: java.lang.Object.class before any calls: 0 bytes after getDeclaredConstructors: 192 bytes after getDeclaredFields: 192 bytes after getDeclaredMethods: 1,552 bytes after getConstructors: 1,552 bytes after getFields: 1,568 bytes after getMethods: 1,680 bytes Deep size of ReflectionData in: java.lang.String.class before any calls: 0 bytes after getDeclaredConstructors: 1,816 bytes after getDeclaredFields: 2,368 bytes after getDeclaredMethods: 10,704 bytes after getConstructors: 10,784 bytes after getFields: 10,832 bytes after getMethods: 12,096 bytes Deep size of ReflectionData in: java.util.HashMap.class before any calls: 0 bytes after getDeclaredConstructors: 472 bytes after getDeclaredFields: 1,328 bytes after getDeclaredMethods: 5,856 bytes after getConstructors: 5,856 bytes after getFields: 5,888 bytes after getMethods: 7,024 bytes Deep size of ReflectionData in: javax.swing.JTable.class before any calls: 0 bytes after getDeclaredConstructors: 784 bytes after getDeclaredFields: 4,224 bytes after getDeclaredMethods: 26,072 bytes after getConstructors: 26,072 bytes after getFields: 27,520 bytes after getMethods: 62,960 bytes My micro-benchmarks show no performance degradations with changed caching logic. So what do you think, David? Regards, Peter On 12/14/2012 05:59 AM, David Holmes wrote: Hi Peter, On 13/12/2012 10:27 PM, Peter Levart wrote: On 12/13/2012 11:46 AM, David Holmes wrote: snip I also found code-paths that evaluated reflectionData()
Re: ReflectionData space optimization in java.lang.Class (JEP-149)
Hi Peter, We have to be careful not to disrupt the dynamics of things too much. Duplicate copies wastes memory but doing the replacement wastes time. If we could be purely memory focused then we would do anything to save memory, but we can't do that - we're trying to save some memory without being too disruptive to performance aspects. The more changes like this that are made the less idea we have about the impact on existing reflection-using applications. And we don't have any compelling use-case to motivate this. So I'm inclined to not take this additional step at this time. Thanks, David On 17/12/2012 3:26 AM, Peter Levart wrote: Hi David, Mandy, Joel and others, I prepared the 3rd revision of the patch: http://dl.dropbox.com/u/101777488/jdk8-tl/JEP-149.c/webrev.03/index.html Changes from the 1st revision (disregard 2nd revision) are as follows: - The split of reflectionData() method into short fast-path and longer slow-path newReflectionData() as already proposed in 2nd revision of the patch. - The logic of privateGetDeclared[Fields|Methods|Constructors](boolean publicOnly) methods has been rewritten to eliminate caching of duplicate Field/Method/Constructor instances for the same field, method or constructor. As it turns out, the same public Member can be cached twice. One instance in ReflectionData.declared[Fields|Methods|Constructors] array and the other instance in ReflectionData.declaredPublic[Fields|Methods] or publicConstructors array. These arrays pairs (declared/declaredPublic) retain distinct instances, because they are obtained by separate calls to VM which always constructs new instances. The new proposed logic eliminates duplicate instances, but does not otherwise present any new overhead. It never requests more data from VM then needed at a particular moment (it may request less data from VM if external calls are issued in a particular order). Some applications may benefit from saved allocated space if they request declared members and public members on same Class instances. Here's the comparison of bytes allocated for the ReflectionData object in some Class instances after invoking particular reflection methods: *** *** Original JDK8 privateGetDeclaredXXX methods: *** Deep size of ReflectionData in: java.lang.Object.class before any calls: 0 bytes after getDeclaredConstructors: 192 bytes after getDeclaredFields: 192 bytes after getDeclaredMethods: 1,552 bytes after getConstructors: 1,664 bytes after getFields: 1,696 bytes after getMethods: 2,856 bytes Deep size of ReflectionData in: java.lang.String.class before any calls: 704 bytes after getDeclaredConstructors: 2,472 bytes after getDeclaredFields: 2,472 bytes after getDeclaredMethods: 10,808 bytes after getConstructors: 12,464 bytes after getFields: 12,712 bytes after getMethods: 21,056 bytes Deep size of ReflectionData in: java.util.HashMap.class before any calls: 0 bytes after getDeclaredConstructors: 472 bytes after getDeclaredFields: 1,328 bytes after getDeclaredMethods: 5,856 bytes after getConstructors: 6,360 bytes after getFields: 6,392 bytes after getMethods: 9,576 bytes Deep size of ReflectionData in: javax.swing.JTable.class before any calls: 0 bytes after getDeclaredConstructors: 784 bytes after getDeclaredFields: 4,224 bytes after getDeclaredMethods: 26,072 bytes after getConstructors: 26,792 bytes after getFields: 28,600 bytes after getMethods: 79,912 bytes *** *** With modified privateGetDeclaredXXX methods: *** Deep size of ReflectionData in: java.lang.Object.class before any calls: 0 bytes after getDeclaredConstructors: 192 bytes after getDeclaredFields: 192 bytes after getDeclaredMethods: 1,552 bytes after getConstructors: 1,552 bytes after getFields: 1,568 bytes after getMethods: 1,680 bytes Deep size of ReflectionData in: java.lang.String.class before any calls: 0 bytes after getDeclaredConstructors: 1,816 bytes after getDeclaredFields: 2,368 bytes after getDeclaredMethods: 10,704 bytes after getConstructors: 10,784 bytes after getFields: 10,832 bytes after getMethods: 12,096 bytes Deep size of ReflectionData in: java.util.HashMap.class before any calls: 0 bytes after getDeclaredConstructors: 472 bytes after getDeclaredFields: 1,328 bytes after getDeclaredMethods: 5,856 bytes after getConstructors: 5,856 bytes after getFields: 5,888 bytes after getMethods: 7,024 bytes Deep size of ReflectionData in: javax.swing.JTable.class before any calls: 0 bytes after getDeclaredConstructors: 784 bytes after getDeclaredFields: 4,224 bytes after getDeclaredMethods: 26,072 bytes after getConstructors: 26,072 bytes after getFields: 27,520 bytes after getMethods: 62,960 bytes My micro-benchmarks show no performance degradations with changed caching logic. So what do you think, David? Regards, Peter On 12/14/2012 05:59 AM, David Holmes wrote: Hi Peter, On 13/12/2012 10:27 PM, Peter Levart wrote: On 12/13/2012 11:46 AM, David Holmes wrote: snip I also found code-paths that
Re: Proposal: Fully Concurrent ClassLoading
On 17/12/2012 2:12 AM, Zhong Yu wrote: On Sat, Dec 15, 2012 at 3:24 AM, David Holmesdavid.hol...@oracle.com wrote: Can you suggest any actual use of the result of getClassLoadingLock() that won't cause a NullPointerException if null is returned? I'm saying a more specific exception could be more helpful than NPE, for example, UnsupportedOperationException(getClassLoadingLock() not supported in a fully concurrent class loader) Okay - noted. Thanks, David
Re: signatures that are recorded for default methods
On 15/12/2012 1:01 AM, Paul Benedict wrote: David, forgive me for lousy sentence construction :-) There's no way to say The default implementation does... and not have it be part of the interface spec. Whatever the default method does becomes the stated contract for any other implementation of OpenJDK. That need not be true and that is exactly what has yet to be determined. The precedent already exists with implementation notes in existing JDK classes. Such notes do not constrain others who wish to provide an implementation of the JDK. David - Paul On Fri, Dec 14, 2012 at 12:21 AM, David Holmesdavid.hol...@oracle.com wrote: Paul, On 14/12/2012 9:46 AM, Paul Benedict wrote: Lance, Good questions. Someone with authority will surely answer, but here's my armchair opinion... If the Javadoc is to specify how the default method executes, than that would naturally infer all default implementations must have a stated contract. You can't document the default execution behavior in the public API and then let a provider switch the behavior. The two go hand-in-hand, imo. I couldn't really make sense of that. :) The method has a contract. The default implementation has to honor that contract. The question is whether how the default implementation honors the method contract is required to be part of a second contract. I hope that made sense :) David - Paul On Thu, Dec 13, 2012 at 5:30 PM, Lance Andersen - Oracle lance.ander...@oracle.com wrote: On Dec 13, 2012, at 6:16 PM, Leonid Arbuzov wrote: Good point, Joe. Those extra assertions for default methods can be checked by regular API tests separately from signature tests. I am not clear on this. See the message attached from David which ask a similar question (from the attached email): --- 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. --- If everyone needs to implement the same default implementation then great the JCK/TCK can test it and IMHO we should have a javadoc tag for this. If everyone is free to choose what the default behavior is, then we cannot test it. So has there been a decision WRT the requirements for default methods? Best Lance Thanks, -leonid On 12/13/2012 1:05 PM, Joe Darcy wrote: Hello, As with concrete methods on abstract classes, I would expect the specifications of the default methods to often contain text akin to This default implementation does x, y, and z since if the method is to be called by subtypes, the self-use patterns in the default method need to be known. Cheers, -Joe On 12/13/2012 11:24 AM, Leonid Arbouzov wrote: Hello Lance, My understanding would be that the signature test should check that interface method is marked as default method but do not track the code in its default body (assuming that the body is not a part of a spec - API javadoc). (I've confirmed that with the signature test developer) Thanks, -leonid On 12/6/2012 9:01 AM, Lance Andersen - Oracle wrote: Folks, Will the signatures for interfaces that are recorded by the TCKs for interfaces record the fact that a method includes a default method? or will it just record the method definition? I am assuming it will, but I know there has been discussion that a implementor could choose a different default implementation on one of the recent threads that was up for review. I am still trying to understand what our guidelines are, if any for documenting the behavior of the supplied default methods given the javadocs are part of the specification for many APIs (and in some case the only spec). Best Lance 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
Re: RFR : CR8004015 : Add parent interfaces and default methods to basic functional interfaces
On 15/12/2012 4:58 AM, Mike Duigou wrote:
On Dec 13 2012, at 22:28 , David Holmes wrote:
I have added @throws NPE for a number of the default methods. We won't be including
@throws NPE in all cases where null is disallowed because when the @throws NPE is
declared the API is required to throw NPE in that circumstance. So for cases where the
NPE is naturally thrown or that aren't performance sensitive we will likely
add @throws NPE declarations but for performance sensitive methods we won't be adding
explicit null checks to match a @throws NPE specification. There's a tradeoff here in
some cases. Please feel free to quibble about specific cases as they occur. :-)
That doesn't make sense to me. The throwing of the NPE is intended to be part
of the specification not an implementation choice. Further @param foo non-null,
is just as binding on implementations as @throws NPE if foo is null. ???
An @param foo non-null by itself is not considered normative because it doesn't
document what happens when null is passed. So it ends up being advisory only. An @throws
NPE is considered normative and the implementation must throw in all circumstances described.
Aside: that is an interesting interpretation but from whence does it
come? It is non-normative by definition because it is incomplete? Or is
it just non-normative because it is an @param tag?
(Please bear with the step-by-step nature of the following sample, it's
incremental pace is not meant to be insulting--it's a write-up for a general
FAQ). If I have a method:
But once you add the @throws the advisory of the @param is redundant.
Hence to me it is an either/or situation. Further the advisory, being
advisory, is useless in my opinion, so not something to use regardless.
David
-
/**
* If the object is visible then write it's string form to the provided
PrintStream.
*
* @param bar destination for display
/
public void display(PrintStream bar) {
if(visible) {
bar.write(toString());
}
}
This implementation isn't going to work well if bar is ever null. So I document that in
the @param bar:
/**
* If the object is visible then write it's string form to the provided
PrintStream.
*
* @param bar destination for display, must be non-null
/
public void display(PrintStream bar) {
if(visible) {
bar.write(toString());
}
}
The @param bar documentation now says that it must be non-null but doesn't explain what
happens if null is passed. Having documented that null shouldn't be passed is helpful but not as
helpful as it could be. To specify what happens I must add @throws NPE:
/**
* If the object is visible then write it's string form to the provided
PrintStream.
*
* @param bar destination for display, must be non-null
* @throws NullPointerException if bar is null
/
public void display(PrintStream bar) {
if(visible) {
bar.write(toString());
}
}
This implementation would superficially seem to conform to the contract described in the javadoc.
However, when the if(visible) conditional is false then no NPE will be thrown. Contract
broken. It is required to add an explicit null check on bar ie.
/**
* If the object is visible then write it's string form to the provided
PrintStream.
*
* @param bar destination for display, must be non-null
* @throws NullPointerException if bar is null
/
public void display(PrintStream bar) {
Objects.requireNonNull(bar);
if(visible) {
bar.write(toString());
}
}
Adding the Objects.requireNonNull ensures that the NPE is thrown in all
appropriate cases. There is also another alternative:
/**
* If the object is visible then write it's string form to the provided
PrintStream.
*
* @param bar destination for display, must be non-null
* @throws NullPointerException if bar is null and the component is visible.
/
public void display(PrintStream bar) {
if(visible) {
bar.write(toString());
}
}
The conditions in which NPE are thrown are amended so that throwing is only
required if the component is visible. Documenting the conditions could quickly
become complicated if display was a more involved method. At some point it
becomes easier to just add an explicit check. It can also be useful to add
explicit NPE checks as pre-conditions before a multi-stage operation where a
late stage NPE might corrupt the object state.
In a very few cases an explicit null check might add too much overhead to a performance sensitive method and
writing an accurate @throws NPE isn't possible (perhaps because of delegation) then the
@throws NPE should be removed and only the advisory @param bar ... must be non-null
will have to suffice.
Mike
I think defining the NPE via the @param and @throws is a lose-lose situation:
! * @param left {@inheritDoc}, must be non-null
! * @param right {@inheritDoc}, must be non-null
! * @return {@inheritDoc}, always non-null
! * @throws NullPointerException if {@code left} or {@code right} is null
You only need one
hg: jdk8/tl/jdk: 7197159: accept different kvno if there no match
Changeset: eaaec81aa974 Author:weijun Date: 2012-12-17 12:18 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eaaec81aa974 7197159: accept different kvno if there no match Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/EncryptionKey.java ! test/sun/security/krb5/auto/DynamicKeytab.java + test/sun/security/krb5/auto/KvnoNA.java ! test/sun/security/krb5/auto/MoreKvno.java
hg: jdk8/tl/langtools: 4 new changesets
Changeset: e9a13a6c9d5d Author:katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e9a13a6c9d5d Added tag jdk8-b67 for changeset 303b09787a69 ! .hgtags Changeset: 014a6a11dfe5 Author:lana Date: 2012-12-10 20:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/014a6a11dfe5 Merge - test/tools/javac/defaultMethodExecution/DefaultMethodRegressionTests.java - test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java - test/tools/javac/lambda/LambdaConversionTest.java Changeset: 13ccb5269f3d Author:katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/13ccb5269f3d Added tag jdk8-b68 for changeset 014a6a11dfe5 ! .hgtags Changeset: f72dc656a306 Author:lana Date: 2012-12-16 22:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f72dc656a306 Merge
hg: jdk8/tl: 13 new changesets
Changeset: 98a7af257bee Author:erikj Date: 2012-12-03 10:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/98a7af257bee 8003819: build-infra: backslashes at end of LIB and INCLUDE in spec.gmk Summary: Removing trailing backslash from LIB and INCLUDE. Reviewed-by: ohrstrom, ohair ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain_windows.m4 Changeset: 754f91d22e1c Author:erikj Date: 2012-12-05 09:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/754f91d22e1c 8001541: Cannot build on Solaris using softlinks Summary: Fixed softlink resolver macro in configure. Reviewed-by: tbell, ohair ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: ec187d02c95e Author:erikj Date: 2012-12-05 10:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ec187d02c95e 8004281: build-infra: Move all jar creation to images target and put jars in images/lib Summary: Fixed bug in setting up make dependencies in SetupArchive. Reviewed-by: ohair, tbell, dholmes ! common/makefiles/JavaCompilation.gmk Changeset: bd32ef0789ca Author:erikj Date: 2012-12-05 16:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/bd32ef0789ca 8003414: build-infra: fails on on windows Summary: Added extra check that windows sdk is valid. Reviewed-by: tbell, ohrstrom, ohair ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain_windows.m4 Changeset: 9a6ec97ec45c Author:katleman Date: 2012-12-05 12:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/9a6ec97ec45c Merge Changeset: c91c581321ce Author:katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c91c581321ce Added tag jdk8-b67 for changeset 9a6ec97ec45c ! .hgtags Changeset: 04435608c613 Author:lana Date: 2012-12-10 20:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/04435608c613 Merge Changeset: 6b96b7744913 Author:erikj Date: 2012-12-07 17:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6b96b7744913 8004045: build-infra: Error 12 from zip when updating src.zip Summary: Hiding this error from make so that it doesn't fail Reviewed-by: ohrstrom, dholmes ! common/makefiles/JavaCompilation.gmk Changeset: 2795874efd16 Author:erikj Date: 2012-12-11 11:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2795874efd16 8003945: build-infra: problems finding compiler when using --with-dev-kit Summary: Search all compiler names in dev-kit dir first. Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: e175ecff1391 Author:erikj Date: 2012-12-11 11:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e175ecff1391 8001753: build-infra: mismatch with full debug symbol control for hotspot Summary: Enabling hotspot to use the FDS settings established at configure time Reviewed-by: dholmes, ohair ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/makefiles/NativeCompilation.gmk Changeset: cdb401a60cea Author:katleman Date: 2012-12-12 13:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cdb401a60cea Merge Changeset: e9ec00893bb4 Author:katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e9ec00893bb4 Added tag jdk8-b68 for changeset cdb401a60cea ! .hgtags Changeset: 2ed5be3dd506 Author:lana Date: 2012-12-16 22:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2ed5be3dd506 Merge
hg: jdk8/tl/corba: 2 new changesets
Changeset: 82000531feaa Author:katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/82000531feaa Added tag jdk8-b67 for changeset 394515ad2a55 ! .hgtags Changeset: 22ddcac208a8 Author:katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/22ddcac208a8 Added tag jdk8-b68 for changeset 82000531feaa ! .hgtags
hg: jdk8/tl/jaxws: 2 new changesets
Changeset: d3fe408f3a9a Author:katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d3fe408f3a9a Added tag jdk8-b67 for changeset eb06aa51dfc2 ! .hgtags Changeset: 756323c99011 Author:katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/756323c99011 Added tag jdk8-b68 for changeset d3fe408f3a9a ! .hgtags
hg: jdk8/tl/jdk: 31 new changesets
Changeset: b0f008ab45d7 Author:twisti Date: 2012-11-30 11:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b0f008ab45d7 8001885: JSR 292 classes should use jdk.internal.org.objectweb.asm Reviewed-by: kvn, jrose, twisti Contributed-by: David Chase david.r.ch...@oracle.com ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Changeset: 0fda013e4638 Author:erikj Date: 2012-12-05 10:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0fda013e4638 8004281: build-infra: Move all jar creation to images target and put jars in images/lib Reviewed-by: ohair, tbell, dholmes ! makefiles/CompileDemos.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/Images.gmk ! makefiles/Import.gmk Changeset: ce9b02a3a17e Author:katleman Date: 2012-12-05 12:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce9b02a3a17e Merge Changeset: ea0d3a9d0d01 Author:katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ea0d3a9d0d01 Added tag jdk8-b67 for changeset ce9b02a3a17e ! .hgtags Changeset: 39f9b2cc5738 Author:bae Date: 2012-11-28 12:28 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39f9b2cc5738 4649812: GIFImageReader handles transparency incorrectly Reviewed-by: bae, prr Contributed-by: Vadim Pakhnushev vadim.pakhnus...@oracle.com ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java Changeset: 6569819eb2fe Author:bae Date: 2012-11-28 12:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6569819eb2fe 5082749: GIF stream metadata specification of aspect ratio is incorrect Reviewed-by: bae, prr Contributed-by: Vadim Pakhnushev vadim.pakhnus...@oracle.com ! src/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html Changeset: 934595726263 Author:bae Date: 2012-11-28 14:12 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/934595726263 7064516: ImageIO.read() fails to load an image Reviewed-by: jgodinez, prr ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/awt/image/ColorConvertOp.java + test/sun/java2d/cmm/ColorConvertOp/InvalidRenderIntentTest.java Changeset: d54db1e16b97 Author:bae Date: 2012-11-30 11:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d54db1e16b97 7124223: [macosx] Regression test failure with new exception, when glyph is positioned explicitly Reviewed-by: jgodinez ! src/share/classes/sun/print/PathGraphics.java Changeset: bd3b3cda125d Author:lana Date: 2012-11-30 16:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd3b3cda125d Merge Changeset: 3c5bf5ed45a9 Author:bae Date: 2012-12-03 16:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c5bf5ed45a9 7124347: [macosx] java.lang.InternalError: not implemented yet on call Graphics2D.drawRenderedImage Reviewed-by: prr, flar ! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceDataProxy.java + test/sun/java2d/OpenGL/CustomCompositeTest.java Changeset: 1175410d98ea Author:serb Date: 2012-11-21 15:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1175410d98ea 7124552: [macosx] NullPointerException in getBufferStrategy() 7124219: [macosx] Unable to draw images to fullscreen Reviewed-by: bae, anthony ! src/macosx/classes/sun/awt/CGraphicsConfig.java ! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java ! src/macosx/classes/sun/lwawt/LWCanvasPeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java + src/macosx/classes/sun/lwawt/LWGraphicsConfig.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: 5b2c31d20a64 Author:serb Date: 2012-11-21 15:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b2c31d20a64 7193214: Consider simplifying CPlatformWindow.setResizable() Reviewed-by: anthony, denis ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m Changeset: c9dead63607c Author:serb Date: 2012-11-21 15:58 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9dead63607c 7154516: [macosx] Popup menus have no visible borders Reviewed-by: anthony, denis ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java Changeset: 9cd48409539e Author:kizune Date: 2012-11-21 20:42 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9cd48409539e 8003273: Missing testcase for 7171812 Reviewed-by: art, serb + test/javax/swing/dnd/7171812/JListWithScroll.java +
hg: jdk8/tl/hotspot: 48 new changesets
Changeset: e1d42ba865de Author:amurillo Date: 2012-11-16 09:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e1d42ba865de 8003541: new hotspot build - hs25-b11 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 49cbd3e25ba9 Author:zgu Date: 2012-11-16 09:05 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/49cbd3e25ba9 8003487: NMT: incorrect assertion in VMMemPointerIterator::remove_released_region method (memSnapshot.cpp) Summary: The assertion is applied to only the region to be released, also performs region integrity checking Reviewed-by: acorn, coleenp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp Changeset: 3ed6de6e139b Author:coleenp Date: 2012-11-20 20:27 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3ed6de6e139b Merge Changeset: 73e64867adb7 Author:mikael Date: 2012-11-21 09:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/73e64867adb7 8003690: Example code in JVMTI GetStackTrace documentation is broken Summary: Fixed to minor errors in example code Reviewed-by: sspitsyn, dholmes ! src/share/vm/prims/jvmti.xml Changeset: 6b881a6b0665 Author:dholmes Date: 2012-11-21 20:07 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6b881a6b0665 8003591: Abstract_VM_Version::internal_vm_info_string needs to stringify FLOAT_ARCH for ease of use Reviewed-by: coleenp, kvn ! src/share/vm/runtime/vm_version.cpp Changeset: ca1be5fbe6ff Author:dholmes Date: 2012-11-21 21:26 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca1be5fbe6ff Merge Changeset: 7c15faa95ce7 Author:mikael Date: 2012-11-27 07:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7c15faa95ce7 8003879: Duplicate definitions in vmStructs Summary: Removed duplicate entries Reviewed-by: dholmes, sspitsyn ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmStructs.hpp Changeset: bbc14465e7db Author:zgu Date: 2012-11-28 09:19 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bbc14465e7db 8003689: MemTracker::init_tracking_options() reads outside array if commandline argument is empty Summary: Fixed potential buffer overrun when giving empty option to NativeMemoryTracking commandline option Reviewed-by: ctornqvi, hseigel, kvn ! src/share/vm/services/memTracker.cpp Changeset: 5de2a5bd519e Author:zgu Date: 2012-11-28 06:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5de2a5bd519e Merge Changeset: fe81517cfb77 Author:hseigel Date: 2012-11-28 08:17 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fe81517cfb77 6924920: Class Data Sharing limit on the java version string can create failures Summary: Truncate the java version string and add a hash value if it is too long. Reviewed-by: dholmes, coleenp ! src/share/vm/memory/filemap.cpp Changeset: b51dc8df86e5 Author:coleenp Date: 2012-11-28 08:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b51dc8df86e5 Merge Changeset: 59c790074993 Author:coleenp Date: 2012-11-28 17:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/59c790074993 8003635: NPG: AsynchGetCallTrace broken by Method* virtual call Summary: Make metaspace::contains be lock free and used to see if something is in metaspace, also compare Method* with vtbl pointer. Reviewed-by: dholmes, sspitsyn, dcubed, jmasa ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/compiledICHolder.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 53715fb1597d Author:brutisso Date: 2012-11-20 11:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/53715fb1597d 7198334: UseNUMA modifies system parameters on non-NUMA system Summary: The flags MinHeapDeltaBytes and UseNUMAInterleaving must be adjusted after the OS have adjusted the UseNUMA flag in the method os::init_2. Reviewed-by: dholmes, brutisso Contributed-by: erik.he...@oracle.com ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/thread.cpp Changeset: 19c1bd641922 Author:coleenp Date: 2012-11-26 12:31 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/19c1bd641922 8003722: More gcc 4.7 compilation errors Summary: Add a few more this-qualifications. Reviewed-by: coleenp, dholmes Contributed-by: dubo...@ssw.jku.at !
