Re: Preliminary review: Adding tracing of I/O calls
Staffan, Has dynamic instrumentation being considered for this project? I realize it would require knowledge of the sites to instrument and I realize that ignoring non-blocking I/O complicates it a bit too, I'm just wondering if you've done any experiments to see if this would be an alternative to the static instrumentation proposed. -Alan
Re: bottleneck by java.lang.Class.getAnnotations() - a better patch
On 11/05/2012 06:23 AM, David Holmes wrote:
Hi Peter,
Moving the annotations fields into a helper object would tie in with
the Class-instance size reduction effort that was investigated as part
of "JEP 149: Reduce Core-Library Memory Usage":
http://openjdk.java.net/jeps/149
The investigations there to date only looked at relocating the
reflection related fields, though the JEP mentions the annotations as
well.
Any such effort requires extensive benchmarking and performance
analysis before being accepted though.
David
-
On 11/05/2012 10:25 AM, Alan Bateman wrote:
Here's a good starting place on the interaction of runtime visible
attributes and RedefineClasses/RetransformClasses:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002251
-Alan.
Hi all,
Presented here is a patch mainly against java.lang.Class and also
against java.lang.reflect.[Field,Method,Constructor,Executable] classes.
Currently java.lang.Class uses the following fields to maintain caches
of reflection data that are invalidated as a result of class or
superclass redefinition/re-transformation:
private volatile transient SoftReference declaredFields;
private volatile transient SoftReference publicFields;
private volatile transient SoftReference declaredMethods;
private volatile transient SoftReference publicMethods;
private volatile transient SoftReference[]>
declaredConstructors;
private volatile transient SoftReference[]>
publicConstructors;
private volatile transient SoftReference declaredPublicFields;
private volatile transient SoftReference
declaredPublicMethods;
// Value of classRedefinedCount when we last cleared the cached values
// that are sensitive to class redefinition.
private volatile transient int lastRedefinedCount = 0;
// Annotations cache
private transient Map, Annotation>
annotations;
private transient Map, Annotation>
declaredAnnotations;
If I understand Alan's references correctly, current VM can redefine the
class in a way that changes method bodies. Also new methods can be
added. And the set of annotations can also be altered. And future
improvements could allow even more.
Because annotations are cached on Field/Method/Constructor instances,
all the above fields must be invalidated when the class or superclass is
redefined.
It can also be observed that Field/Method/Constructor caches are
maintained using SoftReferences but annotations are hard references. I
don't know if this is intentional. I believe that annotations could also
be SoftReferenced, so that in the event of memory pressure they get
cleared. Many applications retrieve annotations only in the early stages
of their life-cycle and then either cache them themselves or forget
about them.
So I designed the patch to equalize this. If this is undesirable, the
patch could be modified to make a distinction again.
The patch replaces the above-mentioned java.lang.Class fields with a
single field:
private volatile transient SoftReference> volatileData;
...which is a SoftReference to the following structure:
// volatile data that might get invalid when JVM TI
RedefineClasses() is called
static class VolatileData {
volatile Field[] declaredFields;
volatile Field[] publicFields;
volatile Method[] declaredMethods;
volatile Method[] publicMethods;
volatile Constructor[] declaredConstructors;
volatile Constructor[] publicConstructors;
// Intermediate results for getFields and getMethods
volatile Field[] declaredPublicFields;
volatile Method[] declaredPublicMethods;
// Annotations
volatile Map, Annotation> annotations;
volatile Map, Annotation>
declaredAnnotations;
// Value of classRedefinedCount when we created this
VolatileData instance
final int redefinedCount;
So let's look at static overhead differences using 64 bit addressing
(useful load - arrays, Maps not counted since the patched code uses the
same amount of same types of each).
* Fresh java.lang.Class instance:
current JDK8 code:
10 OOPs + 1 int = 10*8+4 = 84 bytes in 1 instance
vs. patched code :
1 OOP = 8 bytes in 1 instance
* Fully loaded java.lang.Class (Fields, Methods, Constructors, annotations):
current JDK8 code:
10 OOPs + 1 int = 84 bytes
8 SoftReference instances = 8*(header + 4 OOPs + 1 long) = 8*(24+32+8) =
8*64 = 512 bytes
total: 84+512 = 596 bytes in 9 instances
vs. patched code :
1 OOP = 8 bytes
1 SoftReference = 64 bytes
1 VolatileData = header + 10 OOPs + 1 int = 24+84 = 108 bytes
total: 8+64+108 = 180 bytes in 3 instances
So we have 84 vs. 8 (empty) or 596 vs. 180 (fully loaded) byte overheads and
1 vs. 1 (empty) or 9 vs. 3 (fully loaded) instance overheads
Other than that, the patch also removes synchronized blocks for lazy
initialization of annotations in Class, Field, Method and Constructor
and replaces them with volatile
Re: Preliminary review: Adding tracing of I/O calls
No, I haven't considered dynamic instrumentation. It would be a lot more work to implement it, and only worth it, I think, if the performance of the static instrumentation is bad. One could do a little of both: leave the static instrumentation in place, but change the IoTrace class to have only empty methods, then do dynamic instrumentation in that class. /Staffan On 6 nov 2012, at 13:23, Alan Bateman wrote: > Staffan, > > Has dynamic instrumentation being considered for this project? I realize it > would require knowledge of the sites to instrument and I realize that > ignoring non-blocking I/O complicates it a bit too, I'm just wondering if > you've done any experiments to see if this would be an alternative to the > static instrumentation proposed. > > -Alan
Re: bottleneck by java.lang.Class.getAnnotations() - a better patch
Peter, I haven't studied your patch yet but moving the fields into a helper class is what was envisaged. Here's another reminder that the initialization has been crying out to be re-worked for some time: http://bugs.sun.com/view_bug.do?bug_id=7122142 -Alan.
Re: bottleneck by java.lang.Class.getAnnotations() - a better patch
On 11/06/2012 03:00 PM, Alan Bateman wrote: Peter, I haven't studied your patch yet but moving the fields into a helper class is what was envisaged. Here's another reminder that the initialization has been crying out to be re-worked for some time: http://bugs.sun.com/view_bug.do?bug_id=7122142 -Alan. I noticed the static syncronized AnnotationType.getInstance too. My proposed patch does away with synchronized Class.initAnnotationsIfNecessary and replaces it with plain Class.privateGetAnnotations that doesn't use any locks. Therefore it solves this deadlock. Regards, Peter
hg: jdk8/tl/langtools: 8002286: Regression: Fix for 8000931 causes a JCK test failure
Changeset: 9b85813d2262 Author:mcimadamore Date: 2012-11-06 14:45 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9b85813d2262 8002286: Regression: Fix for 8000931 causes a JCK test failure Summary: Wrong type used as 'site' in Resolve.resolveMethod Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/8002286/T8002286.java + test/tools/javac/8002286/T8002286.out
Re: 7197491: update copyright year to match last edit in jdk8 jdk repository
On Nov 4, 2012, at 2:04 AM, David Holmes wrote: > On 3/11/2012 3:27 AM, Kelly O'Hair wrote: >> All changes to JDK sources require a CR, an OpenJDK author name, and a >> review by a second OpenJDK author. >> So although you can automate the preparation of the commit, you cannot fully >> automate this process. >> >> There have been many discussions over the years about automating various >> changes, anything from tag generation, >> to whitespace normalization, and this copyright year change issue. >> Our policy has been that changesets need human authors, and all changes need >> a human review. > > I think that is the tail wagging the dog. A simple change to a year value in > a comment by a sanctioned pre/post commit script can easily be accommodated > in the changeset for a given CR just as-if the engineer had done it > themselves. In the SCCS days we didn't require reviews for sccs tag updates > in file headers - I don't see that copyright update should be any different. > If we need to tweak the OpenJDK rules then lets tweak them. But in SCCS days, you still needed an identity on the change, an informal review, and a human to trigger the putback. It is true that in the SCCS days there was less red tape, but in the SCCS days there was much less tracking of all changes, and identities could be fictitious. The SCCS history was generally worthless. > > Personally I don't see why it is so hard to have engineers be responsible for > this (if automation is considered so problematic). It only affects one > changeset per file per year and a pre-commit script (or jcheck enhancement?) > could warn you if you forget to do the update. I find these big periodic > changesets far more noisy and problematic. > The only issue would be that warnings tend to be ignored by most developers, but I could accept this idea. If jcheck blocked the commit when it detected a missing year change, that would force the edit before the changeset would be created, or before the changeset was integrated. However, I'm not exactly sure we could make the copyright year check that concrete, maybe, it's not as cut and dried as the whitespace check jcheck does. > For the general audience: copyright years only get updated when there is a > substantive change to the material content of a file. I think we well and > truly established that when we went through the Sun to Oracle conversion > process. Yes. There are very rare situations where a file can change, and that change should not trigger a year update. So by default, we treat any change to a file as being one that needs a year update. --- Just to clarify it for others: And there are 2 years. The first year is the initial creation, the second year is the year of last change. When they are the same, one year will be listed in the legal notice. It's very important to preserve that first year, or year of creation. -kto > > David > >> -kto >> >> On Nov 2, 2012, at 9:51 AM, Darryl Mocek wrote: >> >>> So the 3000+ files Alan is referring to are all files which have been >>> modified but which haven't had their year updated? If we're not worried >>> about files which haven't been modified then a pre/post-commit script will >>> suffice and depending on how we implement it we might not need periodic >>> updates. >>> >>> Darryl >>> >>> On 11/02/2012 09:47 AM, Phil Race wrote: > but ultimately there are files which never get touched which will need > processing to update the year. The policy has varied over the years, but presently the policy is not to update the year in files that have not been updated code-wise. -phil. On 11/2/2012 9:37 AM, Darryl Mocek wrote: > Alan, > >I was responsible for updating the copyrights for JavaME. I used a > Perl script to update the copyright year in the source files. I can > point you to the relevant information if you like. There were challenges > as there are various copyrights in the source files (Oracle, Oracle + > 3rd-party, 3rd party only, and no copyright), all with different formats, > and even within the Oracle copyrights, people used subtle differences > which caused difficulties. I ended updating all copyrights to a few > formats and adding a post-commit script which scrubbed the copyright and > notified the committer if the copyright wasn't in the correct format and > didn't have an ending year (or sole year) which is the current year. > > There are plenty of options here: > > - Do nothing (policy) > - Pre-commit script which changes the year automatically > - Pre-commit script which rejects commit with wrong year > - Post-commit script which flags a bad copyright, but accepts commit > - Others > > Updating the copyright year as you commit is a good habit to get into, > but ultimately there are files which never get touched which will need > proces
hg: jdk8/tl/jdk: 8002297: sun/net/www/protocol/http/StackTraceTest.java fails intermittently
Changeset: 157506182fa7 Author:chegar Date: 2012-11-06 21:01 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/157506182fa7 8002297: sun/net/www/protocol/http/StackTraceTest.java fails intermittently Reviewed-by: alanb, dsamersoff ! test/sun/net/www/protocol/http/StackTraceTest.java
Fake DNS query result inside a test
Hi Vinnie
I want to write a regression test so that
Context ctx = NamingManager.getURLContext("dns", new Hashtable<>(0));
Attributes attrs =((DirContext)ctx).getAttributes(
"_kerberos._udp.ASDF.COM.", SRV_RR_ATTR);
can return some entries without querying a real external server.
Is this possible by registering a local name server provider or else?
Thanks
Max
hg: jdk8/tl/langtools: 7198690: missing compiler message
Changeset: 55a007aaf63d Author:jjg Date: 2012-11-06 17:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/55a007aaf63d 7198690: missing compiler message Reviewed-by: jjh ! src/share/classes/com/sun/tools/javac/main/Main.java
Re: bottleneck by java.lang.Class.getAnnotations() - a better patch
Hi Peter,
The movement of the reflection caches to a helper object is exactly what
I had previously proposed here (some differences in the details of course):
http://cr.openjdk.java.net/~dholmes/JEP-149/webrev/
and discussed here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-April/009749.html
but this did not touch the annotations fields.
David
On 6/11/2012 11:12 PM, Peter Levart wrote:
On 11/05/2012 06:23 AM, David Holmes wrote:
Hi Peter,
Moving the annotations fields into a helper object would tie in with
the Class-instance size reduction effort that was investigated as part
of "JEP 149: Reduce Core-Library Memory Usage":
http://openjdk.java.net/jeps/149
The investigations there to date only looked at relocating the
reflection related fields, though the JEP mentions the annotations as
well.
Any such effort requires extensive benchmarking and performance
analysis before being accepted though.
David
-
On 11/05/2012 10:25 AM, Alan Bateman wrote:
Here's a good starting place on the interaction of runtime visible
attributes and RedefineClasses/RetransformClasses:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002251
-Alan.
Hi all,
Presented here is a patch mainly against java.lang.Class and also
against java.lang.reflect.[Field,Method,Constructor,Executable] classes.
Currently java.lang.Class uses the following fields to maintain caches
of reflection data that are invalidated as a result of class or
superclass redefinition/re-transformation:
private volatile transient SoftReference declaredFields;
private volatile transient SoftReference publicFields;
private volatile transient SoftReference declaredMethods;
private volatile transient SoftReference publicMethods;
private volatile transient SoftReference[]>
declaredConstructors;
private volatile transient SoftReference[]>
publicConstructors;
private volatile transient SoftReference declaredPublicFields;
private volatile transient SoftReference declaredPublicMethods;
// Value of classRedefinedCount when we last cleared the cached values
// that are sensitive to class redefinition.
private volatile transient int lastRedefinedCount = 0;
// Annotations cache
private transient Map, Annotation> annotations;
private transient Map, Annotation>
declaredAnnotations;
If I understand Alan's references correctly, current VM can redefine the
class in a way that changes method bodies. Also new methods can be
added. And the set of annotations can also be altered. And future
improvements could allow even more.
Because annotations are cached on Field/Method/Constructor instances,
all the above fields must be invalidated when the class or superclass is
redefined.
It can also be observed that Field/Method/Constructor caches are
maintained using SoftReferences but annotations are hard references. I
don't know if this is intentional. I believe that annotations could also
be SoftReferenced, so that in the event of memory pressure they get
cleared. Many applications retrieve annotations only in the early stages
of their life-cycle and then either cache them themselves or forget
about them.
So I designed the patch to equalize this. If this is undesirable, the
patch could be modified to make a distinction again.
The patch replaces the above-mentioned java.lang.Class fields with a
single field:
private volatile transient SoftReference> volatileData;
...which is a SoftReference to the following structure:
// volatile data that might get invalid when JVM TI RedefineClasses() is
called
static class VolatileData {
volatile Field[] declaredFields;
volatile Field[] publicFields;
volatile Method[] declaredMethods;
volatile Method[] publicMethods;
volatile Constructor[] declaredConstructors;
volatile Constructor[] publicConstructors;
// Intermediate results for getFields and getMethods
volatile Field[] declaredPublicFields;
volatile Method[] declaredPublicMethods;
// Annotations
volatile Map, Annotation> annotations;
volatile Map, Annotation> declaredAnnotations;
// Value of classRedefinedCount when we created this VolatileData instance
final int redefinedCount;
So let's look at static overhead differences using 64 bit addressing
(useful load - arrays, Maps not counted since the patched code uses the
same amount of same types of each).
* Fresh java.lang.Class instance:
current JDK8 code:
10 OOPs + 1 int = 10*8+4 = 84 bytes in 1 instance
vs. patched code :
1 OOP = 8 bytes in 1 instance
* Fully loaded java.lang.Class (Fields, Methods, Constructors, annotations):
current JDK8 code:
10 OOPs + 1 int = 84 bytes
8 SoftReference instances = 8*(header + 4 OOPs + 1 long) = 8*(24+32+8) =
8*64 = 512 bytes
total: 84+512 = 596 bytes in 9 instances
vs. patched code :
1 OOP = 8 bytes
1 SoftReference = 64 bytes
1 VolatileData = header + 10 OOPs + 1 int = 24+84 = 108 bytes
total: 8+64+108 = 180 bytes in 3 instances
So we have 84 vs. 8 (empty) or 596 vs. 180 (fully loaded) byte overheads and
1 vs. 1 (empty) or 9 vs. 3 (fully loaded) instance
Re: 7197491: update copyright year to match last edit in jdk8 jdk repository
On 7/11/2012 2:11 AM, Kelly O'Hair wrote: On Nov 4, 2012, at 2:04 AM, David Holmes wrote: On 3/11/2012 3:27 AM, Kelly O'Hair wrote: All changes to JDK sources require a CR, an OpenJDK author name, and a review by a second OpenJDK author. So although you can automate the preparation of the commit, you cannot fully automate this process. There have been many discussions over the years about automating various changes, anything from tag generation, to whitespace normalization, and this copyright year change issue. Our policy has been that changesets need human authors, and all changes need a human review. I think that is the tail wagging the dog. A simple change to a year value in a comment by a sanctioned pre/post commit script can easily be accommodated in the changeset for a given CR just as-if the engineer had done it themselves. In the SCCS days we didn't require reviews for sccs tag updates in file headers - I don't see that copyright update should be any different. If we need to tweak the OpenJDK rules then lets tweak them. But in SCCS days, you still needed an identity on the change, an informal review, and a human to trigger the putback. It would be no different with hg. In SCCS days you would only see the sccs variable in the code. The update only happens when you "commit". In neither case do the reviewers see the actual change; in both cases there is an identity on the change and a human doing it. Anyway I prefer manual updates with a jcheck check. There are times when a change does not necessitate an update to the copyright year (mainly changes to the copyright notice itself) but these are rare. Cheers, David It is true that in the SCCS days there was less red tape, but in the SCCS days there was much less tracking of all changes, and identities could be fictitious. The SCCS history was generally worthless. Personally I don't see why it is so hard to have engineers be responsible for this (if automation is considered so problematic). It only affects one changeset per file per year and a pre-commit script (or jcheck enhancement?) could warn you if you forget to do the update. I find these big periodic changesets far more noisy and problematic. The only issue would be that warnings tend to be ignored by most developers, but I could accept this idea. If jcheck blocked the commit when it detected a missing year change, that would force the edit before the changeset would be created, or before the changeset was integrated. However, I'm not exactly sure we could make the copyright year check that concrete, maybe, it's not as cut and dried as the whitespace check jcheck does. For the general audience: copyright years only get updated when there is a substantive change to the material content of a file. I think we well and truly established that when we went through the Sun to Oracle conversion process. Yes. There are very rare situations where a file can change, and that change should not trigger a year update. So by default, we treat any change to a file as being one that needs a year update. --- Just to clarify it for others: And there are 2 years. The first year is the initial creation, the second year is the year of last change. When they are the same, one year will be listed in the legal notice. It's very important to preserve that first year, or year of creation. -kto David -kto On Nov 2, 2012, at 9:51 AM, Darryl Mocek wrote: So the 3000+ files Alan is referring to are all files which have been modified but which haven't had their year updated? If we're not worried about files which haven't been modified then a pre/post-commit script will suffice and depending on how we implement it we might not need periodic updates. Darryl On 11/02/2012 09:47 AM, Phil Race wrote: but ultimately there are files which never get touched which will need processing to update the year. The policy has varied over the years, but presently the policy is not to update the year in files that have not been updated code-wise. -phil. On 11/2/2012 9:37 AM, Darryl Mocek wrote: Alan, I was responsible for updating the copyrights for JavaME. I used a Perl script to update the copyright year in the source files. I can point you to the relevant information if you like. There were challenges as there are various copyrights in the source files (Oracle, Oracle + 3rd-party, 3rd party only, and no copyright), all with different formats, and even within the Oracle copyrights, people used subtle differences which caused difficulties. I ended updating all copyrights to a few formats and adding a post-commit script which scrubbed the copyright and notified the committer if the copyright wasn't in the correct format and didn't have an ending year (or sole year) which is the current year. There are plenty of options here: - Do nothing (policy) - Pre-commit script which changes the year automatically - Pre-commit script which rejects commit with
hg: jdk8/tl/corba: 4 new changesets
Changeset: de2b8def2be5 Author:ohair Date: 2012-10-26 14:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/de2b8def2be5 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildCorba.gmk ! makefiles/Makefile Changeset: 6ccbf67b68bf Author:katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/6ccbf67b68bf Merge Changeset: b450c07849ab Author:katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/b450c07849ab Added tag jdk8-b63 for changeset 6ccbf67b68bf ! .hgtags Changeset: 54d599a5b4aa Author:lana Date: 2012-11-02 17:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/54d599a5b4aa Merge
hg: jdk8/tl: 7 new changesets
Changeset: e64f2cb57d05 Author:ohair Date: 2012-10-26 14:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e64f2cb57d05 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell ! NewMakefile.gmk ! common/autoconf/autogen.sh ! common/autoconf/basics.m4 + common/autoconf/basics_windows.m4 ! common/autoconf/boot-jdk.m4 ! common/autoconf/build-aux/config.guess ! common/autoconf/build-performance.m4 ! common/autoconf/builddeps.m4 ! common/autoconf/closed.version.numbers ! common/autoconf/compare.sh.in ! common/autoconf/configure ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/autoconf/libraries.m4 ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 + common/autoconf/toolchain_windows.m4 ! common/autoconf/version.numbers + common/bin/compare.sh + common/bin/compare_exceptions.sh.incl - common/bin/compareimage.sh - common/bin/diffexec.sh - common/bin/diffjarzip.sh - common/bin/difflib.sh - common/bin/difftext.sh - common/bin/exception_list_linux - common/bin/extractvcvars.sh ! common/bin/hide_important_warnings_from_javac.sh ! common/bin/logger.sh + common/bin/shell-tracer.sh - common/bin/unicode2x.sed ! common/makefiles/HotspotWrapper.gmk ! common/makefiles/IdlCompilation.gmk ! common/makefiles/JavaCompilation.gmk + common/makefiles/Main.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/MakeHelpers.gmk ! common/makefiles/Makefile ! common/makefiles/NativeCompilation.gmk ! common/makefiles/RMICompilation.gmk - common/makefiles/compress.post - common/makefiles/compress.pre + common/makefiles/support/ListPathsSafely-post-compress.incl + common/makefiles/support/ListPathsSafely-pre-compress.incl + common/makefiles/support/ListPathsSafely-uncompress.sed + common/makefiles/support/unicode2x.sed - common/makefiles/uncompress.sed + common/src/fixpath.c - common/src/uncygdrive.c + configure Changeset: e3182741ade2 Author:ihse Date: 2012-10-29 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e3182741ade2 8001897: build-infra: misc adjustments to configure script Reviewed-by: ohair ! common/autoconf/Makefile.in ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: 3229597524ca Author:katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3229597524ca Merge - common/bin/compareimage.sh - common/bin/diffexec.sh - common/bin/diffjarzip.sh - common/bin/difflib.sh - common/bin/difftext.sh - common/bin/exception_list_linux - common/bin/extractvcvars.sh - common/bin/unicode2x.sed - common/makefiles/compress.post - common/makefiles/compress.pre - common/makefiles/uncompress.sed - common/src/uncygdrive.c Changeset: cababb9dfce7 Author:katleman Date: 2012-11-01 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cababb9dfce7 Added tag jdk8-b63 for changeset 3229597524ca ! .hgtags Changeset: dd1a80efa7cf Author:anthony Date: 2012-10-30 15:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/dd1a80efa7cf 8001764: vsvars.sh should support VS2012 Summary: Update the vsvars.sh script to support VS2012 Reviewed-by: ohair, tbell ! make/scripts/vsvars.sh Changeset: fc61be4ff6ae Author:lana Date: 2012-10-31 09:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/fc61be4ff6ae Merge ! make/scripts/vsvars.sh Changeset: 65dca75b2a26 Author:lana Date: 2012-11-02 17:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/65dca75b2a26 Merge
hg: jdk8/tl/hotspot: Added tag jdk8-b63 for changeset acabb5c282f5
Changeset: 4d37eb50b9b1 Author:katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4d37eb50b9b1 Added tag jdk8-b63 for changeset acabb5c282f5 ! .hgtags
hg: jdk8/tl/jaxp: 3 new changesets
Changeset: 121fc928a361 Author:ohair Date: 2012-10-26 14:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/121fc928a361 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildJaxp.gmk ! makefiles/Makefile Changeset: 192d8a244bc3 Author:katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/192d8a244bc3 Merge Changeset: 27ab79568c34 Author:katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/27ab79568c34 Added tag jdk8-b63 for changeset 192d8a244bc3 ! .hgtags
hg: jdk8/tl/jaxws: 3 new changesets
Changeset: c30a7cb5c587 Author:ohair Date: 2012-10-26 14:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c30a7cb5c587 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildJaxws.gmk ! makefiles/Makefile Changeset: 86989f702267 Author:katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/86989f702267 Merge Changeset: 5ded18a14bcc Author:katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/5ded18a14bcc Added tag jdk8-b63 for changeset 86989f702267 ! .hgtags
hg: jdk8/tl/langtools: 5 new changesets
Changeset: 741cce355ba6 Author:ohair Date: 2012-10-26 14:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/741cce355ba6 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildLangtools.gmk ! makefiles/Makefile Changeset: 92e6f2190ca0 Author:katleman Date: 2012-10-31 18:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/92e6f2190ca0 Merge Changeset: 26831b6fcc4a Author:katleman Date: 2012-11-01 14:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/26831b6fcc4a Added tag jdk8-b63 for changeset 92e6f2190ca0 ! .hgtags Changeset: e6ee43b3e247 Author:lana Date: 2012-11-02 17:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e6ee43b3e247 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java - src/share/classes/com/sun/tools/javac/code/TypeTags.java Changeset: 6dc8616cea9b Author:lana Date: 2012-11-06 18:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6dc8616cea9b Merge
XS RFR: 8002040 Allow Full Debug Symbols when cross-compiling
webrev: http://cr.openjdk.java.net/~dholmes/8002040/webrev/ This is a simplified variant of the change just made to Hotspot. Instead of disabling FDS when cross-compiling we change the default location of objcopy, and just as with native compilation either the default objcopy is found or we try to fallback to ALT_OBJCOPY if set. In other words the only difference between the two cases is the chosen default. (Arguably both cases could just use COMPILER_PATH/objcopy but that might change existing behaviour in some cases - which we do not want to do). I will push this via the build repo. There are no corresponding changes needed to the new build as it handles FDS differently. This only impacts Linux. Thanks, David
hg: jdk8/tl/jdk: 6355584: Introduce constrained Kerberos delegation
Changeset: a1bbb8805e22 Author:weijun Date: 2012-11-07 14:13 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a1bbb8805e22 6355584: Introduce constrained Kerberos delegation Reviewed-by: valeriep + src/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java ! src/share/classes/sun/security/jgss/GSSCaller.java ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/share/classes/sun/security/jgss/HttpCaller.java ! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java + src/share/classes/sun/security/jgss/krb5/Krb5ProxyCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/share/classes/sun/security/jgss/spi/GSSCredentialSpi.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java ! src/share/classes/sun/security/jgss/spnego/SpNegoCredElement.java ! src/share/classes/sun/security/jgss/wrapper/GSSCredElement.java ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/EncryptedData.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/KrbKdcRep.java ! src/share/classes/sun/security/krb5/KrbTgsRep.java ! src/share/classes/sun/security/krb5/KrbTgsReq.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/share/classes/sun/security/krb5/internal/EncKDCRepPart.java ! src/share/classes/sun/security/krb5/internal/KDCOptions.java ! src/share/classes/sun/security/krb5/internal/Krb5.java ! src/share/classes/sun/security/krb5/internal/PAData.java + src/share/classes/sun/security/krb5/internal/PAForUserEnc.java ! src/share/classes/sun/security/krb5/internal/crypto/KeyUsage.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! test/sun/security/krb5/auto/Basic.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/CrossRealm.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/OkAsDelegate.java + test/sun/security/krb5/auto/S4U2proxy.java + test/sun/security/krb5/auto/S4U2proxyGSS.java + test/sun/security/krb5/auto/S4U2self.java + test/sun/security/krb5/auto/S4U2selfAsServer.java + test/sun/security/krb5/auto/S4U2selfAsServerGSS.java + test/sun/security/krb5/auto/S4U2selfGSS.java
