From chris.hegarty at oracle.com Sun Jan 1 11:54:21 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 01 Jan 2012 11:54:21 +0000 Subject: hg: jdk8/tl/jdk: 7125055: ContentHandler.getContent API changed in error Message-ID: <20120101115447.590E647858@hg.openjdk.java.net> Changeset: 5aeefe0e5d8c Author: chegar Date: 2012-01-01 09:24 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5aeefe0e5d8c 7125055: ContentHandler.getContent API changed in error Reviewed-by: alanb ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/sun/net/www/content/image/gif.java ! src/share/classes/sun/net/www/content/image/jpeg.java ! src/share/classes/sun/net/www/content/image/png.java ! src/share/classes/sun/net/www/content/image/x_xbitmap.java ! src/share/classes/sun/net/www/content/image/x_xpixmap.java From kumar.x.srinivasan at oracle.com Tue Jan 3 16:29:04 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 03 Jan 2012 16:29:04 +0000 Subject: hg: jdk8/tl/jdk: 7123582: (launcher) display the -version and -XshowSettings Message-ID: <20120103162914.97A394785E@hg.openjdk.java.net> Changeset: 8952a5f494f9 Author: ksrini Date: 2012-01-03 08:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8952a5f494f9 7123582: (launcher) display the -version and -XshowSettings Reviewed-by: alanb ! src/share/bin/java.c ! test/tools/launcher/Settings.java From kumar.x.srinivasan at oracle.com Tue Jan 3 16:36:05 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 03 Jan 2012 16:36:05 +0000 Subject: hg: jdk8/tl/jdk: 7124443: (launcher) test DefaultsLocaleTest fails with Windows shells. Message-ID: <20120103163615.67A264785F@hg.openjdk.java.net> Changeset: 5e34726cb4bb Author: ksrini Date: 2012-01-03 08:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e34726cb4bb 7124443: (launcher) test DefaultsLocaleTest fails with Windows shells. Reviewed-by: darcy ! test/tools/launcher/DefaultLocaleTest.java - test/tools/launcher/DefaultLocaleTest.sh + test/tools/launcher/DefaultLocaleTestRun.java ! test/tools/launcher/TestHelper.java From jonathan.gibbons at oracle.com Tue Jan 3 19:37:41 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 03 Jan 2012 19:37:41 +0000 Subject: hg: jdk8/tl/langtools: 4881269: improve diagnostic for ill-formed tokens Message-ID: <20120103193744.D72C447860@hg.openjdk.java.net> Changeset: 7a836147b266 Author: jjg Date: 2012-01-03 11:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7a836147b266 4881269: improve diagnostic for ill-formed tokens Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/IllegalDot.java + test/tools/javac/parser/T4881269.java + test/tools/javac/parser/T4881269.out From jim.holmlund at sun.com Wed Jan 4 01:19:06 2012 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Wed, 04 Jan 2012 01:19:06 +0000 Subject: hg: jdk8/tl/langtools: 7046929: tools/javac/api/T6397104.java fails Message-ID: <20120104011908.8E5474786C@hg.openjdk.java.net> Changeset: a07eef109532 Author: jjh Date: 2012-01-03 17:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a07eef109532 7046929: tools/javac/api/T6397104.java fails Reviewed-by: jjg ! test/tools/javac/api/T6397104.java From frederic.parain at oracle.com Wed Jan 4 13:26:27 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 04 Jan 2012 13:26:27 +0000 Subject: hg: jdk8/tl/jdk: 7104647: Adding a diagnostic command framework Message-ID: <20120104132648.F151947874@hg.openjdk.java.net> Changeset: 0194fe5ca404 Author: fparain Date: 2012-01-04 03:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0194fe5ca404 7104647: Adding a diagnostic command framework Reviewed-by: mchung, dholmes ! make/common/Release.gmk ! make/java/management/mapfile-vers ! make/launchers/Makefile ! make/sun/tools/Makefile + src/linux/doc/man/jcmd.1 + src/share/classes/com/sun/management/DiagnosticCommandArgumentInfo.java + src/share/classes/com/sun/management/DiagnosticCommandInfo.java ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java + src/share/classes/sun/tools/jcmd/Arguments.java + src/share/classes/sun/tools/jcmd/JCmd.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/HotSpotDiagnostic.c + src/solaris/doc/sun/man/man1/jcmd.1 + test/com/sun/management/HotSpotDiagnosticMXBean/ExecuteDiagnosticCommand.java + test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommandInfo.java + test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommands.java ! test/sun/tools/common/CommonSetup.sh + test/sun/tools/jcmd/dcmd-script.txt + test/sun/tools/jcmd/help_help.out + test/sun/tools/jcmd/jcmd-Defaults.sh + test/sun/tools/jcmd/jcmd-f.sh + test/sun/tools/jcmd/jcmd-help-help.sh + test/sun/tools/jcmd/jcmd-help.sh + test/sun/tools/jcmd/jcmd-pid.sh + test/sun/tools/jcmd/jcmd_Output1.awk + test/sun/tools/jcmd/jcmd_pid_Output1.awk + test/sun/tools/jcmd/jcmd_pid_Output2.awk + test/sun/tools/jcmd/usage.out From alan.bateman at oracle.com Fri Jan 6 15:01:57 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 06 Jan 2012 15:01:57 +0000 Subject: hg: jdk8/tl/jdk: 7127235: (fs) NPE in Files.walkFileTree if cached attributes are GC'ed Message-ID: <20120106150224.844CE478CF@hg.openjdk.java.net> Changeset: 400cc379adb5 Author: alanb Date: 2012-01-06 15:00 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/400cc379adb5 7127235: (fs) NPE in Files.walkFileTree if cached attributes are GC'ed Reviewed-by: forax, chegar ! src/share/classes/java/nio/file/FileTreeWalker.java From valerie.peng at oracle.com Fri Jan 6 19:05:01 2012 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Fri, 06 Jan 2012 19:05:01 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120106190520.A8FB5478D2@hg.openjdk.java.net> Changeset: cdc128128044 Author: valeriep Date: 2012-01-05 18:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdc128128044 6414899: P11Digest should support cloning Summary: Enhanced the PKCS11 Digest implementation to support cloning Reviewed-by: vinnie ! make/sun/security/pkcs11/mapfile-vers ! src/share/classes/sun/security/pkcs11/P11Digest.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java ! src/share/lib/security/sunpkcs11-solaris.cfg ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h + test/sun/security/pkcs11/MessageDigest/TestCloning.java Changeset: e6ef778c1df4 Author: valeriep Date: 2012-01-06 11:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6ef778c1df4 Merge From valerie.peng at oracle.com Sat Jan 7 00:12:58 2012 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Sat, 07 Jan 2012 00:12:58 +0000 Subject: hg: jdk8/tl/jdk: 7033170: Cipher.getMaxAllowedKeyLength(String) throws NoSuchAlgorithmException Message-ID: <20120107001308.B7DB7478D8@hg.openjdk.java.net> Changeset: 6720ae7b1448 Author: valeriep Date: 2012-01-06 16:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6720ae7b1448 7033170: Cipher.getMaxAllowedKeyLength(String) throws NoSuchAlgorithmException Summary: Changed to always use full transformation as provider properties. Reviewed-by: mullan ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! test/javax/crypto/Cipher/GetMaxAllowed.java From joe.darcy at oracle.com Sat Jan 7 03:13:07 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Sat, 07 Jan 2012 03:13:07 +0000 Subject: hg: jdk8/tl/jdk: 7123649: Remove public modifier from Math.powerOfTwoF. Message-ID: <20120107031317.03BA7478DB@hg.openjdk.java.net> Changeset: 2050ff9dfc92 Author: darcy Date: 2012-01-06 18:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2050ff9dfc92 7123649: Remove public modifier from Math.powerOfTwoF. Reviewed-by: smarks, alanb ! src/share/classes/java/lang/Math.java From alan.bateman at oracle.com Mon Jan 9 19:33:51 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 09 Jan 2012 19:33:51 +0000 Subject: hg: jdk8/tl/jdk: 7030573: test/java/io/FileInputStream/LargeFileAvailable.java fails when there is insufficient disk space Message-ID: <20120109193414.B83CB478F2@hg.openjdk.java.net> Changeset: 74c92c3e66ad Author: gadams Date: 2012-01-09 19:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74c92c3e66ad 7030573: test/java/io/FileInputStream/LargeFileAvailable.java fails when there is insufficient disk space Reviewed-by: alanb ! test/java/io/FileInputStream/LargeFileAvailable.java From joe.darcy at oracle.com Mon Jan 9 23:55:51 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 09 Jan 2012 23:55:51 +0000 Subject: hg: jdk8/tl/jdk: 7128441: StrictMath performance improvement note shared with Math Message-ID: <20120109235609.65D34478F6@hg.openjdk.java.net> Changeset: 858038d89fd5 Author: darcy Date: 2012-01-09 15:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/858038d89fd5 7128441: StrictMath performance improvement note shared with Math Reviewed-by: darcy Contributed-by: Martin Desruisseaux ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java From joe.darcy at oracle.com Tue Jan 10 04:14:46 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 10 Jan 2012 04:14:46 +0000 Subject: hg: jdk8/tl/jdk: 7128512: Javadoc typo in java.lang.invoke.MethodHandle Message-ID: <20120110041508.719D4478FB@hg.openjdk.java.net> Changeset: dd69d3695cee Author: darcy Date: 2012-01-09 20:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd69d3695cee 7128512: Javadoc typo in java.lang.invoke.MethodHandle Reviewed-by: mduigou ! src/share/classes/java/lang/invoke/MethodHandle.java From weijun.wang at oracle.com Tue Jan 10 05:41:16 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 10 Jan 2012 13:41:16 +0800 Subject: code review request: 7118809: rcache deadlock In-Reply-To: <7296394.1325559670063.JavaMail.sbladm@swsblss4-new> References: <7296394.1325559670063.JavaMail.sbladm@swsblss4-new> Message-ID: <4F0BCF7C.4060400@oracle.com> Hi Valerie Please review my fix: http://cr.openjdk.java.net/~weijun/7118809/webrev.00/ Basically, CacheTable.put() operates on ReplayCache inside it, and ReplayCache.put() operates on CacheTable containing it, and both methods are synchronized and using thread-safe Hashtable. My solution is to move the "table.remove(principal)" line in ReplayCache.put() outside the method. I search thru JDK and CacheTable.put() is the only place the method is called: public synchronized void put(String principal, AuthTime time, long currTime) { ReplayCache rc = super.get(principal); if (rc == null) { if (DEBUG) { System.out.println("replay cache for " + principal + " is null."); } rc = new ReplayCache(principal, this); rc.put(time, currTime); super.put(principal, rc); } else { rc.put(time, currTime); // re-insert the entry, since rc.put could have removed the entry super.put(principal, rc); if (DEBUG) { System.out.println("replay cache found."); } } } Curiously, you can see after each call, the ReplayCache object is added back into the CacheTable. Therefore, the remove action is useless. Maybe the most correct way is to remove a ReplayCache from a CacheTable if it's empty, but that re-insert line was added in a security fix some years ago which I cannot decipher. So my fix simply removes the "remove" call in ReplayCache. No regression test, hard to reproduce failure. Thanks Max -------- Original Message -------- *Change Request ID*: 7118809 *Synopsis*: rcache deadlock === *Description* ============================================================ A DESCRIPTION OF THE PROBLEM : The program as below: -------------------------------------------------- import sun.security.krb5.internal.rcache.*; import sun.security.krb5.internal.*; import java.util.*; public class KTest2 { public static void main(String [] a) throws Exception{ final CacheTable ct = new CacheTable(); final long time = System.currentTimeMillis(); ct.put("TheOnlyOne", new AuthTime( time - Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * 1000L, 0), time); final ReplayCache rc = (ReplayCache) ct.get("TheOnlyOne"); new Thread() { public void run() { rc.put(new AuthTime( time - Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * 1000L, 0), time + 300*1000); } }.start(); ct.put("TheOnlyOne", new AuthTime( time - Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * 1000L, 0), time); } } -------------------------------------------------- When compiles as in: javac KTest2.java and executed as in: java KTest2 can deadlock the hosting JVM as is reproduced by the stack-trace dump, below: ------------------------------------------------- Found one Java-level deadlock: ============================= "Thread-0": waiting to lock monitor 0x0921d720 (object 0xa5621b80, a sun.security.krb5.internal.rcache.CacheTable), which is held by "main" "main": waiting to lock monitor 0x0921caa0 (object 0xa5622fb8, a sun.security.krb5.internal.rcache.ReplayCache), which is held by "Thread-0" Java stack information for the threads listed above: =================================================== "Thread-0": at java.util.Hashtable.remove(Hashtable.java:435) - waiting to lock <0xa5621b80> (a sun.security.krb5.internal.rcache.CacheTable) at sun.security.krb5.internal.rcache.ReplayCache.put(ReplayCache.java:123) - locked <0xa5622fb8> (a sun.security.krb5.internal.rcache.ReplayCache) at KTest2$1.run(KTest2.java:13) "main": at sun.security.krb5.internal.rcache.ReplayCache.put(ReplayCache.java:62) - waiting to lock <0xa5622fb8> (a sun.security.krb5.internal.rcache.ReplayCache) at sun.security.krb5.internal.rcache.CacheTable.put(CacheTable.java:59) - locked <0xa5621b80> (a sun.security.krb5.internal.rcache.CacheTable) at KTest2.main(KTest2.java:16) Found 1 deadlock. ... From chris.hegarty at oracle.com Tue Jan 10 12:46:12 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 10 Jan 2012 12:46:12 +0000 Subject: hg: jdk8/tl/jdk: 7123415: Some cases of network interface indexes being read incorrectly Message-ID: <20120110124633.CD6EE47901@hg.openjdk.java.net> Changeset: d72de8b3fe36 Author: chegar Date: 2012-01-10 10:57 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d72de8b3fe36 7123415: Some cases of network interface indexes being read incorrectly Reviewed-by: chegar Contributed-by: brandon.passanisi at oracle.com ! src/solaris/native/java/net/net_util_md.c From chris.hegarty at oracle.com Tue Jan 10 12:49:14 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 10 Jan 2012 12:49:14 +0000 Subject: hg: jdk8/tl/jdk: 7128584: Typo in sun.misc.VM's private directMemory field comment Message-ID: <20120110124923.C329247902@hg.openjdk.java.net> Changeset: bba276a6aa0d Author: chegar Date: 2012-01-10 12:48 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bba276a6aa0d 7128584: Typo in sun.misc.VM's private directMemory field comment Reviewed-by: forax, chegar Contributed-by: Krystal Mok ! src/share/classes/sun/misc/VM.java From xuelei.fan at oracle.com Tue Jan 10 14:51:02 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 10 Jan 2012 22:51:02 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 In-Reply-To: <4ECAEFAC.2090305@oracle.com> References: <4EBCAE01.6060308@oracle.com> <4EBCC1C4.5030802@oracle.com> <4EC524EC.1020104@oracle.com> <4EC643D9.7080601@oracle.com> <4EC651FC.2070202@oracle.com> <4EC668DA.2060106@oracle.com> <4EC66DDB.4060702@oracle.com> <4EC66F04.2070005@oracle.com> <4EC713D8.5010209@oracle.com> <4EC9FE23.2060508@oracle.com> <4ECA0D15.3040707@oracle.com> <4ECA3E71.7090707@oracle.com> <4ECAEFAC.2090305@oracle.com> Message-ID: <4F0C5056.4020709@oracle.com> It has been around 50 days passed since the last day we talked about the issue. Hope you can recall it from the deep memory. ;-) webrev: http://javaweb.us.oracle.com/~xufan/bugbios/7106773/webrev.04/ In this update, as we agreed, a new Oracle private interface was introduced: sun.security.util.Lengthable, and Lengthable.length() is defined to get the length an object. sun.security.pkcs11.P11Key and sun.security.mscapi.Key will implements the interface. As will easy and speedup (comparing with reflection approach) the getting of key length of those unextractable keys in hardware device. In the webrev, I should also include another two signed jars, sunpkcs11.jar and sunmscapi.jar. I will include them when I get the official signed jars. Thanks, Xuelei On 11/22/2011 8:41 AM, Weijun Wang wrote: > I really like this one. > > Thanks > Max > > On 11/21/2011 08:05 PM, Xuelei Fan wrote: >>> > How about this approach? This looks very safe. >>> > >> I also prefer this approach, although it need more updates in PKCS11 and >> MSCPI source code. If you vote for this approach, I will try to >> implement it. >> From weijun.wang at oracle.com Tue Jan 10 15:09:20 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 10 Jan 2012 23:09:20 +0800 Subject: =?gb2312?B?tPC4tDogQ29kZSByZXZpZXcgcmVxdWVzdCwgNzEwNjc3MzogNTEyIGJpdHMg?= =?gb2312?B?UlNBIGtleSBjYW5ub3Qgd29yayB3aXRoU0hBMzg0IGFuZCBTSEE1MTI=?= Message-ID: <201201101509.q0AF92CS000982@acsmt358.oracle.com> It's late night and I'll read it tomorrow. But can you choose another word instead of Lengthable? Length is not a verb. Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Jan 10 15:19:32 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 10 Jan 2012 23:19:32 +0800 Subject: =?GB2312?B?tPC4tDogQ29kZSByZXZpZXcgcmVxdWVzdCwgNzEwNjc3MzogNQ==?= =?GB2312?B?MTIgYml0cyBSU0Ega2V5IGNhbm5vdCB3b3JrIHdpdGhTSEEzODQgYW5kIFNIQQ==?= =?GB2312?B?NTEy?= Message-ID: <4F0C5704.9040405@oracle.com> On 1/10/2012 11:09 PM, Weijun Wang wrote: > It's late night and I'll read it tomorrow. But can you choose another > word instead of Lengthable? Length is not a verb. > ;-) The name took me a lot of time, searching by google, dictionary, and any possible English translation. I have to agree that I failed to find a suitable name. I tried hardly to persuade myself that "lengthable" is also used by someother application code, so it might not too bad to use it here. With the word "lengthable", I want to express that the length is measurable. Any suggestion for the better one? Thanks, Xuelei > Max > ------------------------------------------------------------------------ > ???: Xuelei Fan > ????: 2012/1/10 22:51 > ???: Weijun Wang > ??: OpenJDK > ??: Re: Code review request, 7106773: 512 bits RSA key cannot work > withSHA384 and SHA512 > > It has been around 50 days passed since the last day we talked about the > issue. Hope you can recall it from the deep memory. ;-) > > webrev: http://javaweb.us.oracle.com/~xufan/bugbios/7106773/webrev.04/ > > In this update, as we agreed, a new Oracle private interface was > introduced: sun.security.util.Lengthable, and Lengthable.length() is > defined to get the length an object. sun.security.pkcs11.P11Key and > sun.security.mscapi.Key will implements the interface. As will easy and > speedup (comparing with reflection approach) the getting of key length > of those unextractable keys in hardware device. > > In the webrev, I should also include another two signed jars, > sunpkcs11.jar and sunmscapi.jar. I will include them when I get the > official signed jars. > > Thanks, > Xuelei > > On 11/22/2011 8:41 AM, Weijun Wang wrote: >> I really like this one. >> >> Thanks >> Max >> >> On 11/21/2011 08:05 PM, Xuelei Fan wrote: >>>> > How about this approach? This looks very safe. >>>> > >>> I also prefer this approach, although it need more updates in PKCS11 and >>> MSCPI source code. If you vote for this approach, I will try to >>> implement it. >>> > From vincent.x.ryan at oracle.com Tue Jan 10 15:47:39 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 10 Jan 2012 15:47:39 +0000 Subject: =?GB2312?B?tPC4tDogQ29kZSByZXZpZXcgcmVxdWVzdCwgNzEwNjc3MzogNQ==?= =?GB2312?B?MTIgYml0cyBSU0Ega2V5IGNhbm5vdCB3b3JrIHdpdGhTSEEzODQgYW5kIFNIQQ==?= =?GB2312?B?NTEy?= In-Reply-To: <4F0C5704.9040405@oracle.com> References: <4F0C5704.9040405@oracle.com> Message-ID: <4F0C5D9B.8070303@oracle.com> On 01/10/12 03:19 PM, Xuelei Fan wrote: > On 1/10/2012 11:09 PM, Weijun Wang wrote: >> It's late night and I'll read it tomorrow. But can you choose another >> word instead of Lengthable? Length is not a verb. >> > ;-) The name took me a lot of time, searching by google, dictionary, and > any possible English translation. I have to agree that I failed to find > a suitable name. I tried hardly to persuade myself that "lengthable" is > also used by someother application code, so it might not too bad to use > it here. > > With the word "lengthable", I want to express that the length is > measurable. Any suggestion for the better one? > Measurable ;-) > Thanks, > Xuelei > >> Max >> ------------------------------------------------------------------------ >> ???: Xuelei Fan >> ????: 2012/1/10 22:51 >> ???: Weijun Wang >> ??: OpenJDK >> ??: Re: Code review request, 7106773: 512 bits RSA key cannot work >> withSHA384 and SHA512 >> >> It has been around 50 days passed since the last day we talked about the >> issue. Hope you can recall it from the deep memory. ;-) >> >> webrev: http://javaweb.us.oracle.com/~xufan/bugbios/7106773/webrev.04/ >> >> In this update, as we agreed, a new Oracle private interface was >> introduced: sun.security.util.Lengthable, and Lengthable.length() is >> defined to get the length an object. sun.security.pkcs11.P11Key and >> sun.security.mscapi.Key will implements the interface. As will easy and >> speedup (comparing with reflection approach) the getting of key length >> of those unextractable keys in hardware device. >> >> In the webrev, I should also include another two signed jars, >> sunpkcs11.jar and sunmscapi.jar. I will include them when I get the >> official signed jars. >> >> Thanks, >> Xuelei >> >> On 11/22/2011 8:41 AM, Weijun Wang wrote: >>> I really like this one. >>> >>> Thanks >>> Max >>> >>> On 11/21/2011 08:05 PM, Xuelei Fan wrote: >>>>>> How about this approach? This looks very safe. >>>>>> >>>> I also prefer this approach, although it need more updates in PKCS11 and >>>> MSCPI source code. If you vote for this approach, I will try to >>>> implement it. >>>> >> > From xuelei.fan at oracle.com Wed Jan 11 00:57:22 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 11 Jan 2012 08:57:22 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work withSHA384 and SHA512 In-Reply-To: <4F0C5D9B.8070303@oracle.com> References: <4F0C5704.9040405@oracle.com> <4F0C5D9B.8070303@oracle.com> Message-ID: <4F0CDE72.50408@oracle.com> "Measurable" looks like a better name. I will update the name in the next webrev after this round of code review: webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.04/ Thanks, Xuelei On 1/10/2012 11:47 PM, Vincent Ryan wrote: > On 01/10/12 03:19 PM, Xuelei Fan wrote: >> On 1/10/2012 11:09 PM, Weijun Wang wrote: >>> It's late night and I'll read it tomorrow. But can you choose another >>> word instead of Lengthable? Length is not a verb. >>> >> ;-) The name took me a lot of time, searching by google, dictionary, and >> any possible English translation. I have to agree that I failed to find >> a suitable name. I tried hardly to persuade myself that "lengthable" is >> also used by someother application code, so it might not too bad to use >> it here. >> >> With the word "lengthable", I want to express that the length is >> measurable. Any suggestion for the better one? >> > > Measurable ;-) > > >> Thanks, >> Xuelei >> >>> Max >>> ------------------------------------------------------------------------ >>> ???: Xuelei Fan >>> ????: 2012/1/10 22:51 >>> ???: Weijun Wang >>> ??: OpenJDK >>> ??: Re: Code review request, 7106773: 512 bits RSA key cannot work >>> withSHA384 and SHA512 >>> >>> It has been around 50 days passed since the last day we talked about the >>> issue. Hope you can recall it from the deep memory. ;-) >>> >>> webrev: http://javaweb.us.oracle.com/~xufan/bugbios/7106773/webrev.04/ >>> >>> In this update, as we agreed, a new Oracle private interface was >>> introduced: sun.security.util.Lengthable, and Lengthable.length() is >>> defined to get the length an object. sun.security.pkcs11.P11Key and >>> sun.security.mscapi.Key will implements the interface. As will easy and >>> speedup (comparing with reflection approach) the getting of key length >>> of those unextractable keys in hardware device. >>> >>> In the webrev, I should also include another two signed jars, >>> sunpkcs11.jar and sunmscapi.jar. I will include them when I get the >>> official signed jars. >>> >>> Thanks, >>> Xuelei >>> >>> On 11/22/2011 8:41 AM, Weijun Wang wrote: >>>> I really like this one. >>>> >>>> Thanks >>>> Max >>>> >>>> On 11/21/2011 08:05 PM, Xuelei Fan wrote: >>>>>>> How about this approach? This looks very safe. >>>>>>> >>>>> I also prefer this approach, although it need more updates in PKCS11 and >>>>> MSCPI source code. If you vote for this approach, I will try to >>>>> implement it. >>>>> >>> >> > From joe.darcy at oracle.com Wed Jan 11 01:13:02 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 11 Jan 2012 01:13:02 +0000 Subject: hg: jdk8/tl/jdk: 7112008: Javadoc for j.l.Object.finalize() vs JLS 12.6 Finalization of Class Instances Message-ID: <20120111011327.5669247913@hg.openjdk.java.net> Changeset: 49e64a8fc18f Author: darcy Date: 2012-01-10 17:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/49e64a8fc18f 7112008: Javadoc for j.l.Object.finalize() vs JLS 12.6 Finalization of Class Instances Reviewed-by: mduigou ! src/share/classes/java/lang/Object.java From joe.darcy at oracle.com Wed Jan 11 01:47:02 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 11 Jan 2012 01:47:02 +0000 Subject: hg: jdk8/tl/jdk: 7128931: Bad HTML escaping in java.lang.Throwable javadoc Message-ID: <20120111014712.8637A47914@hg.openjdk.java.net> Changeset: 62dbcbe4c446 Author: darcy Date: 2012-01-10 17:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/62dbcbe4c446 7128931: Bad HTML escaping in java.lang.Throwable javadoc Reviewed-by: mduigou ! src/share/classes/java/lang/Throwable.java From weijun.wang at oracle.com Wed Jan 11 07:59:24 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 11 Jan 2012 15:59:24 +0800 Subject: code review request: 7090565: Move test/closed/javax/security/auth/x500/X500Principal/Parse.java to open tests In-Reply-To: <22706477.1316049657228.JavaMail.sbladm@swsblss4-new> References: <22706477.1316049657228.JavaMail.sbladm@swsblss4-new> Message-ID: <4F0D415C.3000706@oracle.com> Hi Sean Webrev at http://cr.openjdk.java.net/~weijun/7090565/webrev.00/ I changed the name to "duke test", and inline a binary file as a byte array (lines 93-99). Thanks Max -------- Original Message -------- *Change Request ID*: 7090565 *Synopsis*: Move test/closed/javax/security/auth/x500/X500Principal/Parse.java to open tests === *Description* ============================================================ We should see if it is feasible to move test/closed/javax/security/auth/x500/X500Principal/Parse.java to the open area. It contains tests for several bugs, none of which are vulnerabilities. From weijun.wang at oracle.com Wed Jan 11 09:50:53 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 11 Jan 2012 17:50:53 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work withSHA384 and SHA512 In-Reply-To: <4F0CDE72.50408@oracle.com> References: <4F0C5704.9040405@oracle.com> <4F0C5D9B.8070303@oracle.com> <4F0CDE72.50408@oracle.com> Message-ID: <4F0D5B7D.4080909@oracle.com> Hi Andrew Take a brief look at the webrev. Looks like this Lengthable thing is the only change after your previous webrev. Please confirm. But I want something bigger. I would like to know if it is possible to add this keysize() method deep down into the very basic Key interface. If Key can have a method called getEncoded() I think this means it normally has a concrete form and surely has a publicly acceptable keysize() attribute. In JDK 8 we have default implementation for new interface methods. Is this issue a good candidate? At least, in KeyLength::getKeySize(), I would like to see "if (key instanceof Lengthable)" to be the first check, and, if possible, the only one needed, at least for keys from providers built in JDK. Thanks Max On 01/11/2012 08:57 AM, Xuelei Fan wrote: > "Measurable" looks like a better name. I will update the name in the > next webrev after this round of code review: > > webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.04/ > > Thanks, > Xuelei > > On 1/10/2012 11:47 PM, Vincent Ryan wrote: >> On 01/10/12 03:19 PM, Xuelei Fan wrote: >>> On 1/10/2012 11:09 PM, Weijun Wang wrote: >>>> It's late night and I'll read it tomorrow. But can you choose another >>>> word instead of Lengthable? Length is not a verb. >>>> >>> ;-) The name took me a lot of time, searching by google, dictionary, and >>> any possible English translation. I have to agree that I failed to find >>> a suitable name. I tried hardly to persuade myself that "lengthable" is >>> also used by someother application code, so it might not too bad to use >>> it here. >>> >>> With the word "lengthable", I want to express that the length is >>> measurable. Any suggestion for the better one? >>> >> >> Measurable ;-) >> >> >>> Thanks, >>> Xuelei >>> >>>> Max >>>> ------------------------------------------------------------------------ >>>> ???: Xuelei Fan >>>> ????: 2012/1/10 22:51 >>>> ???: Weijun Wang >>>> ??: OpenJDK >>>> ??: Re: Code review request, 7106773: 512 bits RSA key cannot work >>>> withSHA384 and SHA512 >>>> >>>> It has been around 50 days passed since the last day we talked about the >>>> issue. Hope you can recall it from the deep memory. ;-) >>>> >>>> webrev: http://javaweb.us.oracle.com/~xufan/bugbios/7106773/webrev.04/ >>>> >>>> In this update, as we agreed, a new Oracle private interface was >>>> introduced: sun.security.util.Lengthable, and Lengthable.length() is >>>> defined to get the length an object. sun.security.pkcs11.P11Key and >>>> sun.security.mscapi.Key will implements the interface. As will easy and >>>> speedup (comparing with reflection approach) the getting of key length >>>> of those unextractable keys in hardware device. >>>> >>>> In the webrev, I should also include another two signed jars, >>>> sunpkcs11.jar and sunmscapi.jar. I will include them when I get the >>>> official signed jars. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 11/22/2011 8:41 AM, Weijun Wang wrote: >>>>> I really like this one. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> On 11/21/2011 08:05 PM, Xuelei Fan wrote: >>>>>>>> How about this approach? This looks very safe. >>>>>>>> >>>>>> I also prefer this approach, although it need more updates in PKCS11 and >>>>>> MSCPI source code. If you vote for this approach, I will try to >>>>>> implement it. >>>>>> >>>> >>> >> > From xuelei.fan at oracle.com Wed Jan 11 10:02:20 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 11 Jan 2012 18:02:20 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work withSHA384 and SHA512 In-Reply-To: <4F0D5B7D.4080909@oracle.com> References: <4F0C5704.9040405@oracle.com> <4F0C5D9B.8070303@oracle.com> <4F0CDE72.50408@oracle.com> <4F0D5B7D.4080909@oracle.com> Message-ID: <4F0D5E2C.5040906@oracle.com> On 1/11/2012 5:50 PM, Weijun Wang wrote: > Hi Andrew > > Take a brief look at the webrev. Looks like this Lengthable thing is the > only change after your previous webrev. Please confirm. > Yes. > But I want something bigger. I would like to know if it is possible to > add this keysize() method deep down into the very basic Key interface. > If Key can have a method called getEncoded() I think this means it > normally has a concrete form and surely has a publicly acceptable > keysize() attribute. In JDK 8 we have default implementation for new > interface methods. Is this issue a good candidate? > As Key is an java interface, we may not be able to add one more method for compatibility reason. We may export the "Lengthable"/"Measurable" interface in JDK 8. It's possible to implement Lengthable in all sub-classes of Key in Oracle provider, but as would involve too many changes. As we need to backport this fix into JDK 7, I think we'd better consider the big picture in the future. > At least, in KeyLength::getKeySize(), I would like to see "if (key > instanceof Lengthable)" to be the first check, and, if possible, the > only one needed, at least for keys from providers built in JDK. > It's OK to check it at first. But as we also need to support other providers, I think we'd better also check other types of instance. Thanks, Xuelei > Thanks > Max > > > On 01/11/2012 08:57 AM, Xuelei Fan wrote: >> "Measurable" looks like a better name. I will update the name in the >> next webrev after this round of code review: >> >> webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.04/ >> >> Thanks, >> Xuelei >> >> On 1/10/2012 11:47 PM, Vincent Ryan wrote: >>> On 01/10/12 03:19 PM, Xuelei Fan wrote: >>>> On 1/10/2012 11:09 PM, Weijun Wang wrote: >>>>> It's late night and I'll read it tomorrow. But can you choose another >>>>> word instead of Lengthable? Length is not a verb. >>>>> >>>> ;-) The name took me a lot of time, searching by google, dictionary, and >>>> any possible English translation. I have to agree that I failed to find >>>> a suitable name. I tried hardly to persuade myself that "lengthable" is >>>> also used by someother application code, so it might not too bad to use >>>> it here. >>>> >>>> With the word "lengthable", I want to express that the length is >>>> measurable. Any suggestion for the better one? >>>> >>> >>> Measurable ;-) >>> >>> >>>> Thanks, >>>> Xuelei >>>> >>>>> Max >>>>> ------------------------------------------------------------------------ >>>>> ???: Xuelei Fan >>>>> ????: 2012/1/10 22:51 >>>>> ???: Weijun Wang >>>>> ??: OpenJDK >>>>> ??: Re: Code review request, 7106773: 512 bits RSA key cannot work >>>>> withSHA384 and SHA512 >>>>> >>>>> It has been around 50 days passed since the last day we talked about the >>>>> issue. Hope you can recall it from the deep memory. ;-) >>>>> >>>>> webrev: http://javaweb.us.oracle.com/~xufan/bugbios/7106773/webrev.04/ >>>>> >>>>> In this update, as we agreed, a new Oracle private interface was >>>>> introduced: sun.security.util.Lengthable, and Lengthable.length() is >>>>> defined to get the length an object. sun.security.pkcs11.P11Key and >>>>> sun.security.mscapi.Key will implements the interface. As will easy and >>>>> speedup (comparing with reflection approach) the getting of key length >>>>> of those unextractable keys in hardware device. >>>>> >>>>> In the webrev, I should also include another two signed jars, >>>>> sunpkcs11.jar and sunmscapi.jar. I will include them when I get the >>>>> official signed jars. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 11/22/2011 8:41 AM, Weijun Wang wrote: >>>>>> I really like this one. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> On 11/21/2011 08:05 PM, Xuelei Fan wrote: >>>>>>>>> How about this approach? This looks very safe. >>>>>>>>> >>>>>>> I also prefer this approach, although it need more updates in PKCS11 and >>>>>>> MSCPI source code. If you vote for this approach, I will try to >>>>>>> implement it. >>>>>>> >>>>> >>>> >>> >> From weijun.wang at oracle.com Wed Jan 11 10:42:52 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 11 Jan 2012 18:42:52 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work withSHA384 and SHA512 In-Reply-To: <4F0D5E2C.5040906@oracle.com> References: <4F0C5704.9040405@oracle.com> <4F0C5D9B.8070303@oracle.com> <4F0CDE72.50408@oracle.com> <4F0D5B7D.4080909@oracle.com> <4F0D5E2C.5040906@oracle.com> Message-ID: <4F0D67AC.5060102@oracle.com> On 01/11/2012 06:02 PM, Xuelei Fan wrote: > On 1/11/2012 5:50 PM, Weijun Wang wrote: >> Hi Andrew >> >> Take a brief look at the webrev. Looks like this Lengthable thing is the >> only change after your previous webrev. Please confirm. >> > Yes. > >> But I want something bigger. I would like to know if it is possible to >> add this keysize() method deep down into the very basic Key interface. >> If Key can have a method called getEncoded() I think this means it >> normally has a concrete form and surely has a publicly acceptable >> keysize() attribute. In JDK 8 we have default implementation for new >> interface methods. Is this issue a good candidate? >> > As Key is an java interface, we may not be able to add one more method > for compatibility reason. We may export the "Lengthable"/"Measurable" > interface in JDK 8. It's possible to implement Lengthable in all > sub-classes of Key in Oracle provider, but as would involve too many > changes. As we need to backport this fix into JDK 7, I think we'd better > consider the big picture in the future. Then I think the previous webrev is enough for JDK 7, and for JDK 8, we simply add a new keysize() method to Key. Max > >> At least, in KeyLength::getKeySize(), I would like to see "if (key >> instanceof Lengthable)" to be the first check, and, if possible, the >> only one needed, at least for keys from providers built in JDK. >> > It's OK to check it at first. But as we also need to support other > providers, I think we'd better also check other types of instance. > > Thanks, > Xuelei > >> Thanks >> Max >> >> >> On 01/11/2012 08:57 AM, Xuelei Fan wrote: >>> "Measurable" looks like a better name. I will update the name in the >>> next webrev after this round of code review: >>> >>> webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.04/ >>> >>> Thanks, >>> Xuelei >>> >>> On 1/10/2012 11:47 PM, Vincent Ryan wrote: >>>> On 01/10/12 03:19 PM, Xuelei Fan wrote: >>>>> On 1/10/2012 11:09 PM, Weijun Wang wrote: >>>>>> It's late night and I'll read it tomorrow. But can you choose another >>>>>> word instead of Lengthable? Length is not a verb. >>>>>> >>>>> ;-) The name took me a lot of time, searching by google, dictionary, and >>>>> any possible English translation. I have to agree that I failed to find >>>>> a suitable name. I tried hardly to persuade myself that "lengthable" is >>>>> also used by someother application code, so it might not too bad to use >>>>> it here. >>>>> >>>>> With the word "lengthable", I want to express that the length is >>>>> measurable. Any suggestion for the better one? >>>>> >>>> >>>> Measurable ;-) >>>> >>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>>> Max >>>>>> ------------------------------------------------------------------------ >>>>>> ???: Xuelei Fan >>>>>> ????: 2012/1/10 22:51 >>>>>> ???: Weijun Wang >>>>>> ??: OpenJDK >>>>>> ??: Re: Code review request, 7106773: 512 bits RSA key cannot work >>>>>> withSHA384 and SHA512 >>>>>> >>>>>> It has been around 50 days passed since the last day we talked about the >>>>>> issue. Hope you can recall it from the deep memory. ;-) >>>>>> >>>>>> webrev: http://javaweb.us.oracle.com/~xufan/bugbios/7106773/webrev.04/ >>>>>> >>>>>> In this update, as we agreed, a new Oracle private interface was >>>>>> introduced: sun.security.util.Lengthable, and Lengthable.length() is >>>>>> defined to get the length an object. sun.security.pkcs11.P11Key and >>>>>> sun.security.mscapi.Key will implements the interface. As will easy and >>>>>> speedup (comparing with reflection approach) the getting of key length >>>>>> of those unextractable keys in hardware device. >>>>>> >>>>>> In the webrev, I should also include another two signed jars, >>>>>> sunpkcs11.jar and sunmscapi.jar. I will include them when I get the >>>>>> official signed jars. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 11/22/2011 8:41 AM, Weijun Wang wrote: >>>>>>> I really like this one. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> On 11/21/2011 08:05 PM, Xuelei Fan wrote: >>>>>>>>>> How about this approach? This looks very safe. >>>>>>>>>> >>>>>>>> I also prefer this approach, although it need more updates in PKCS11 and >>>>>>>> MSCPI source code. If you vote for this approach, I will try to >>>>>>>> implement it. >>>>>>>> >>>>>> >>>>> >>>> >>> > From xuelei.fan at oracle.com Wed Jan 11 10:55:47 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 11 Jan 2012 18:55:47 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work withSHA384 and SHA512 In-Reply-To: <4F0D67AC.5060102@oracle.com> References: <4F0C5704.9040405@oracle.com> <4F0C5D9B.8070303@oracle.com> <4F0CDE72.50408@oracle.com> <4F0D5B7D.4080909@oracle.com> <4F0D5E2C.5040906@oracle.com> <4F0D67AC.5060102@oracle.com> Message-ID: <4F0D6AB3.9030705@oracle.com> On 1/11/2012 6:42 PM, Weijun Wang wrote: > > > On 01/11/2012 06:02 PM, Xuelei Fan wrote: >> On 1/11/2012 5:50 PM, Weijun Wang wrote: >>> Hi Andrew >>> >>> Take a brief look at the webrev. Looks like this Lengthable thing is the >>> only change after your previous webrev. Please confirm. >>> >> Yes. >> >>> But I want something bigger. I would like to know if it is possible to >>> add this keysize() method deep down into the very basic Key interface. >>> If Key can have a method called getEncoded() I think this means it >>> normally has a concrete form and surely has a publicly acceptable >>> keysize() attribute. In JDK 8 we have default implementation for new >>> interface methods. Is this issue a good candidate? >>> >> As Key is an java interface, we may not be able to add one more method >> for compatibility reason. We may export the "Lengthable"/"Measurable" >> interface in JDK 8. It's possible to implement Lengthable in all >> sub-classes of Key in Oracle provider, but as would involve too many >> changes. As we need to backport this fix into JDK 7, I think we'd better >> consider the big picture in the future. > > Then I think the previous webrev is enough for JDK 7, and for JDK 8, we > simply add a new keysize() method to Key. > If we add one new method to Key interfaces. The providers based on JDK 7 and previous releases would have to update their codes so as to implement this new method. As will result in serious compatibility issues. It is possible that we export the "Lengthable" interface, and have Oracle providers support this interface, and suggest other providers to use this interfaces. The previous webrev hurt the performance a little because of reflections. Xuelei > Max > >> >>> At least, in KeyLength::getKeySize(), I would like to see "if (key >>> instanceof Lengthable)" to be the first check, and, if possible, the >>> only one needed, at least for keys from providers built in JDK. >>> >> It's OK to check it at first. But as we also need to support other >> providers, I think we'd better also check other types of instance. >> >> Thanks, >> Xuelei >> >>> Thanks >>> Max >>> >>> >>> On 01/11/2012 08:57 AM, Xuelei Fan wrote: >>>> "Measurable" looks like a better name. I will update the name in the >>>> next webrev after this round of code review: >>>> >>>> webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.04/ >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 1/10/2012 11:47 PM, Vincent Ryan wrote: >>>>> On 01/10/12 03:19 PM, Xuelei Fan wrote: >>>>>> On 1/10/2012 11:09 PM, Weijun Wang wrote: >>>>>>> It's late night and I'll read it tomorrow. But can you choose another >>>>>>> word instead of Lengthable? Length is not a verb. >>>>>>> >>>>>> ;-) The name took me a lot of time, searching by google, dictionary, and >>>>>> any possible English translation. I have to agree that I failed to find >>>>>> a suitable name. I tried hardly to persuade myself that "lengthable" is >>>>>> also used by someother application code, so it might not too bad to use >>>>>> it here. >>>>>> >>>>>> With the word "lengthable", I want to express that the length is >>>>>> measurable. Any suggestion for the better one? >>>>>> >>>>> >>>>> Measurable ;-) >>>>> >>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>>> Max >>>>>>> ------------------------------------------------------------------------ >>>>>>> ???: Xuelei Fan >>>>>>> ????: 2012/1/10 22:51 >>>>>>> ???: Weijun Wang >>>>>>> ??: OpenJDK >>>>>>> ??: Re: Code review request, 7106773: 512 bits RSA key cannot work >>>>>>> withSHA384 and SHA512 >>>>>>> >>>>>>> It has been around 50 days passed since the last day we talked about the >>>>>>> issue. Hope you can recall it from the deep memory. ;-) >>>>>>> >>>>>>> webrev: http://javaweb.us.oracle.com/~xufan/bugbios/7106773/webrev.04/ >>>>>>> >>>>>>> In this update, as we agreed, a new Oracle private interface was >>>>>>> introduced: sun.security.util.Lengthable, and Lengthable.length() is >>>>>>> defined to get the length an object. sun.security.pkcs11.P11Key and >>>>>>> sun.security.mscapi.Key will implements the interface. As will easy and >>>>>>> speedup (comparing with reflection approach) the getting of key length >>>>>>> of those unextractable keys in hardware device. >>>>>>> >>>>>>> In the webrev, I should also include another two signed jars, >>>>>>> sunpkcs11.jar and sunmscapi.jar. I will include them when I get the >>>>>>> official signed jars. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>> On 11/22/2011 8:41 AM, Weijun Wang wrote: >>>>>>>> I really like this one. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>> On 11/21/2011 08:05 PM, Xuelei Fan wrote: >>>>>>>>>>> How about this approach? This looks very safe. >>>>>>>>>>> >>>>>>>>> I also prefer this approach, although it need more updates in PKCS11 and >>>>>>>>> MSCPI source code. If you vote for this approach, I will try to >>>>>>>>> implement it. >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> From weijun.wang at oracle.com Wed Jan 11 11:12:54 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 11 Jan 2012 19:12:54 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work withSHA384 and SHA512 In-Reply-To: <4F0D6AB3.9030705@oracle.com> References: <4F0C5704.9040405@oracle.com> <4F0C5D9B.8070303@oracle.com> <4F0CDE72.50408@oracle.com> <4F0D5B7D.4080909@oracle.com> <4F0D5E2C.5040906@oracle.com> <4F0D67AC.5060102@oracle.com> <4F0D6AB3.9030705@oracle.com> Message-ID: <4F0D6EB6.5080606@oracle.com> On 01/11/2012 06:55 PM, Xuelei Fan wrote: > On 1/11/2012 6:42 PM, Weijun Wang wrote: >> >> >> On 01/11/2012 06:02 PM, Xuelei Fan wrote: >>> On 1/11/2012 5:50 PM, Weijun Wang wrote: >>>> Hi Andrew >>>> >>>> Take a brief look at the webrev. Looks like this Lengthable thing is the >>>> only change after your previous webrev. Please confirm. >>>> >>> Yes. >>> >>>> But I want something bigger. I would like to know if it is possible to >>>> add this keysize() method deep down into the very basic Key interface. >>>> If Key can have a method called getEncoded() I think this means it >>>> normally has a concrete form and surely has a publicly acceptable >>>> keysize() attribute. In JDK 8 we have default implementation for new >>>> interface methods. Is this issue a good candidate? >>>> >>> As Key is an java interface, we may not be able to add one more method >>> for compatibility reason. We may export the "Lengthable"/"Measurable" >>> interface in JDK 8. It's possible to implement Lengthable in all >>> sub-classes of Key in Oracle provider, but as would involve too many >>> changes. As we need to backport this fix into JDK 7, I think we'd better >>> consider the big picture in the future. >> >> Then I think the previous webrev is enough for JDK 7, and for JDK 8, we >> simply add a new keysize() method to Key. >> > If we add one new method to Key interfaces. The providers based on JDK 7 > and previous releases would have to update their codes so as to > implement this new method. As will result in serious compatibility issues. I am talking about the new default method language feature in JDK 8 ([1] Section 11, 12). Then the default impl of Key::keySize() returns -1, default impl of SecretKey::keySize() returns getEncoded().length()*8, etc. > > It is possible that we export the "Lengthable" interface, and have > Oracle providers support this interface, and suggest other providers to > use this interfaces. > > The previous webrev hurt the performance a little because of reflections. Thanks for reminding me this. Yes, those P11 and MSCAPI keys. This webrev is still necessary, and the code changes are fine except for 1. SignatureAndHashAlgorithm.java:283, you left a System.out.println 2. KeyLength.java:58, more System.out.printlns 3. KeyLength.java:88, UnsupportedOperationException, necessary? Thanks Max [1] http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html > > Xuelei > >> Max >> >>> >>>> At least, in KeyLength::getKeySize(), I would like to see "if (key >>>> instanceof Lengthable)" to be the first check, and, if possible, the >>>> only one needed, at least for keys from providers built in JDK. >>>> >>> It's OK to check it at first. But as we also need to support other >>> providers, I think we'd better also check other types of instance. >>> >>> Thanks, >>> Xuelei >>> >>>> Thanks >>>> Max >>>> >>>> >>>> On 01/11/2012 08:57 AM, Xuelei Fan wrote: >>>>> "Measurable" looks like a better name. I will update the name in the >>>>> next webrev after this round of code review: >>>>> >>>>> webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.04/ >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 1/10/2012 11:47 PM, Vincent Ryan wrote: >>>>>> On 01/10/12 03:19 PM, Xuelei Fan wrote: >>>>>>> On 1/10/2012 11:09 PM, Weijun Wang wrote: >>>>>>>> It's late night and I'll read it tomorrow. But can you choose another >>>>>>>> word instead of Lengthable? Length is not a verb. >>>>>>>> >>>>>>> ;-) The name took me a lot of time, searching by google, dictionary, and >>>>>>> any possible English translation. I have to agree that I failed to find >>>>>>> a suitable name. I tried hardly to persuade myself that "lengthable" is >>>>>>> also used by someother application code, so it might not too bad to use >>>>>>> it here. >>>>>>> >>>>>>> With the word "lengthable", I want to express that the length is >>>>>>> measurable. Any suggestion for the better one? >>>>>>> >>>>>> >>>>>> Measurable ;-) >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>>> Max >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> ???: Xuelei Fan >>>>>>>> ????: 2012/1/10 22:51 >>>>>>>> ???: Weijun Wang >>>>>>>> ??: OpenJDK >>>>>>>> ??: Re: Code review request, 7106773: 512 bits RSA key cannot work >>>>>>>> withSHA384 and SHA512 >>>>>>>> >>>>>>>> It has been around 50 days passed since the last day we talked about the >>>>>>>> issue. Hope you can recall it from the deep memory. ;-) >>>>>>>> >>>>>>>> webrev: http://javaweb.us.oracle.com/~xufan/bugbios/7106773/webrev.04/ >>>>>>>> >>>>>>>> In this update, as we agreed, a new Oracle private interface was >>>>>>>> introduced: sun.security.util.Lengthable, and Lengthable.length() is >>>>>>>> defined to get the length an object. sun.security.pkcs11.P11Key and >>>>>>>> sun.security.mscapi.Key will implements the interface. As will easy and >>>>>>>> speedup (comparing with reflection approach) the getting of key length >>>>>>>> of those unextractable keys in hardware device. >>>>>>>> >>>>>>>> In the webrev, I should also include another two signed jars, >>>>>>>> sunpkcs11.jar and sunmscapi.jar. I will include them when I get the >>>>>>>> official signed jars. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>>> On 11/22/2011 8:41 AM, Weijun Wang wrote: >>>>>>>>> I really like this one. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>> On 11/21/2011 08:05 PM, Xuelei Fan wrote: >>>>>>>>>>>> How about this approach? This looks very safe. >>>>>>>>>>>> >>>>>>>>>> I also prefer this approach, although it need more updates in PKCS11 and >>>>>>>>>> MSCPI source code. If you vote for this approach, I will try to >>>>>>>>>> implement it. >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> > From xuelei.fan at oracle.com Wed Jan 11 11:42:32 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 11 Jan 2012 19:42:32 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work withSHA384 and SHA512 In-Reply-To: <4F0D6EB6.5080606@oracle.com> References: <4F0C5704.9040405@oracle.com> <4F0C5D9B.8070303@oracle.com> <4F0CDE72.50408@oracle.com> <4F0D5B7D.4080909@oracle.com> <4F0D5E2C.5040906@oracle.com> <4F0D67AC.5060102@oracle.com> <4F0D6AB3.9030705@oracle.com> <4F0D6EB6.5080606@oracle.com> Message-ID: <4F0D75A8.6070108@oracle.com> On 1/11/2012 7:12 PM, Weijun Wang wrote: > > > On 01/11/2012 06:55 PM, Xuelei Fan wrote: >> On 1/11/2012 6:42 PM, Weijun Wang wrote: >>> >>> >>> On 01/11/2012 06:02 PM, Xuelei Fan wrote: >>>> On 1/11/2012 5:50 PM, Weijun Wang wrote: >>>>> Hi Andrew >>>>> >>>>> Take a brief look at the webrev. Looks like this Lengthable thing is the >>>>> only change after your previous webrev. Please confirm. >>>>> >>>> Yes. >>>> >>>>> But I want something bigger. I would like to know if it is possible to >>>>> add this keysize() method deep down into the very basic Key interface. >>>>> If Key can have a method called getEncoded() I think this means it >>>>> normally has a concrete form and surely has a publicly acceptable >>>>> keysize() attribute. In JDK 8 we have default implementation for new >>>>> interface methods. Is this issue a good candidate? >>>>> >>>> As Key is an java interface, we may not be able to add one more method >>>> for compatibility reason. We may export the "Lengthable"/"Measurable" >>>> interface in JDK 8. It's possible to implement Lengthable in all >>>> sub-classes of Key in Oracle provider, but as would involve too many >>>> changes. As we need to backport this fix into JDK 7, I think we'd better >>>> consider the big picture in the future. >>> >>> Then I think the previous webrev is enough for JDK 7, and for JDK 8, we >>> simply add a new keysize() method to Key. >>> >> If we add one new method to Key interfaces. The providers based on JDK 7 >> and previous releases would have to update their codes so as to >> implement this new method. As will result in serious compatibility issues. > > I am talking about the new default method language feature in JDK 8 ([1] > Section 11, 12). Then the default impl of Key::keySize() returns -1, > default impl of SecretKey::keySize() returns getEncoded().length()*8, etc. > A great feature! >> >> It is possible that we export the "Lengthable" interface, and have >> Oracle providers support this interface, and suggest other providers to >> use this interfaces. >> >> The previous webrev hurt the performance a little because of reflections. > > Thanks for reminding me this. Yes, those P11 and MSCAPI keys. This > webrev is still necessary, and the code changes are fine except for > > 1. SignatureAndHashAlgorithm.java:283, you left a System.out.println > > 2. KeyLength.java:58, more System.out.printlns > Should remove them. > 3. KeyLength.java:88, UnsupportedOperationException, necessary? > I want to reserve the flexibility that we may not be able to get key size from a hardware device. Yes, the exception are not thrown in our implementation. BTW, I will change the interface name from "Lengthable" to "Measurable". Do you want to review more? If not, I will update the code locally and push the changes. Thanks, Xuelei > Thanks > Max > > [1] http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html > >> >> Xuelei >> >>> Max >>> >>>> >>>>> At least, in KeyLength::getKeySize(), I would like to see "if (key >>>>> instanceof Lengthable)" to be the first check, and, if possible, the >>>>> only one needed, at least for keys from providers built in JDK. >>>>> >>>> It's OK to check it at first. But as we also need to support other >>>> providers, I think we'd better also check other types of instance. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>> On 01/11/2012 08:57 AM, Xuelei Fan wrote: >>>>>> "Measurable" looks like a better name. I will update the name in the >>>>>> next webrev after this round of code review: >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.04/ >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 1/10/2012 11:47 PM, Vincent Ryan wrote: >>>>>>> On 01/10/12 03:19 PM, Xuelei Fan wrote: >>>>>>>> On 1/10/2012 11:09 PM, Weijun Wang wrote: >>>>>>>>> It's late night and I'll read it tomorrow. But can you choose another >>>>>>>>> word instead of Lengthable? Length is not a verb. >>>>>>>>> >>>>>>>> ;-) The name took me a lot of time, searching by google, dictionary, and >>>>>>>> any possible English translation. I have to agree that I failed to find >>>>>>>> a suitable name. I tried hardly to persuade myself that "lengthable" is >>>>>>>> also used by someother application code, so it might not too bad to use >>>>>>>> it here. >>>>>>>> >>>>>>>> With the word "lengthable", I want to express that the length is >>>>>>>> measurable. Any suggestion for the better one? >>>>>>>> >>>>>>> >>>>>>> Measurable ;-) >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>>>> Max >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> ???: Xuelei Fan >>>>>>>>> ????: 2012/1/10 22:51 >>>>>>>>> ???: Weijun Wang >>>>>>>>> ??: OpenJDK >>>>>>>>> ??: Re: Code review request, 7106773: 512 bits RSA key cannot work >>>>>>>>> withSHA384 and SHA512 >>>>>>>>> >>>>>>>>> It has been around 50 days passed since the last day we talked about the >>>>>>>>> issue. Hope you can recall it from the deep memory. ;-) >>>>>>>>> >>>>>>>>> webrev: http://javaweb.us.oracle.com/~xufan/bugbios/7106773/webrev.04/ >>>>>>>>> >>>>>>>>> In this update, as we agreed, a new Oracle private interface was >>>>>>>>> introduced: sun.security.util.Lengthable, and Lengthable.length() is >>>>>>>>> defined to get the length an object. sun.security.pkcs11.P11Key and >>>>>>>>> sun.security.mscapi.Key will implements the interface. As will easy and >>>>>>>>> speedup (comparing with reflection approach) the getting of key length >>>>>>>>> of those unextractable keys in hardware device. >>>>>>>>> >>>>>>>>> In the webrev, I should also include another two signed jars, >>>>>>>>> sunpkcs11.jar and sunmscapi.jar. I will include them when I get the >>>>>>>>> official signed jars. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>>>>> >>>>>>>>> On 11/22/2011 8:41 AM, Weijun Wang wrote: >>>>>>>>>> I really like this one. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>> On 11/21/2011 08:05 PM, Xuelei Fan wrote: >>>>>>>>>>>>> How about this approach? This looks very safe. >>>>>>>>>>>>> >>>>>>>>>>> I also prefer this approach, although it need more updates in PKCS11 and >>>>>>>>>>> MSCPI source code. If you vote for this approach, I will try to >>>>>>>>>>> implement it. >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> From weijun.wang at oracle.com Wed Jan 11 12:09:52 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 11 Jan 2012 20:09:52 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work withSHA384 and SHA512 In-Reply-To: <4F0D75A8.6070108@oracle.com> References: <4F0C5704.9040405@oracle.com> <4F0C5D9B.8070303@oracle.com> <4F0CDE72.50408@oracle.com> <4F0D5B7D.4080909@oracle.com> <4F0D5E2C.5040906@oracle.com> <4F0D67AC.5060102@oracle.com> <4F0D6AB3.9030705@oracle.com> <4F0D6EB6.5080606@oracle.com> <4F0D75A8.6070108@oracle.com> Message-ID: <4F0D7C10.6020305@oracle.com> On 01/11/2012 07:42 PM, Xuelei Fan wrote: > On 1/11/2012 7:12 PM, Weijun Wang wrote: >> >> >> On 01/11/2012 06:55 PM, Xuelei Fan wrote: >>> On 1/11/2012 6:42 PM, Weijun Wang wrote: >>>> >>>> >>>> On 01/11/2012 06:02 PM, Xuelei Fan wrote: >>>>> On 1/11/2012 5:50 PM, Weijun Wang wrote: >>>>>> Hi Andrew >>>>>> >>>>>> Take a brief look at the webrev. Looks like this Lengthable thing is the >>>>>> only change after your previous webrev. Please confirm. >>>>>> >>>>> Yes. >>>>> >>>>>> But I want something bigger. I would like to know if it is possible to >>>>>> add this keysize() method deep down into the very basic Key interface. >>>>>> If Key can have a method called getEncoded() I think this means it >>>>>> normally has a concrete form and surely has a publicly acceptable >>>>>> keysize() attribute. In JDK 8 we have default implementation for new >>>>>> interface methods. Is this issue a good candidate? >>>>>> >>>>> As Key is an java interface, we may not be able to add one more method >>>>> for compatibility reason. We may export the "Lengthable"/"Measurable" >>>>> interface in JDK 8. It's possible to implement Lengthable in all >>>>> sub-classes of Key in Oracle provider, but as would involve too many >>>>> changes. As we need to backport this fix into JDK 7, I think we'd better >>>>> consider the big picture in the future. >>>> >>>> Then I think the previous webrev is enough for JDK 7, and for JDK 8, we >>>> simply add a new keysize() method to Key. >>>> >>> If we add one new method to Key interfaces. The providers based on JDK 7 >>> and previous releases would have to update their codes so as to >>> implement this new method. As will result in serious compatibility issues. >> >> I am talking about the new default method language feature in JDK 8 ([1] >> Section 11, 12). Then the default impl of Key::keySize() returns -1, >> default impl of SecretKey::keySize() returns getEncoded().length()*8, etc. >> > A great feature! > >>> >>> It is possible that we export the "Lengthable" interface, and have >>> Oracle providers support this interface, and suggest other providers to >>> use this interfaces. >>> >>> The previous webrev hurt the performance a little because of reflections. >> >> Thanks for reminding me this. Yes, those P11 and MSCAPI keys. This >> webrev is still necessary, and the code changes are fine except for >> >> 1. SignatureAndHashAlgorithm.java:283, you left a System.out.println >> >> 2. KeyLength.java:58, more System.out.printlns >> > Should remove them. > >> 3. KeyLength.java:88, UnsupportedOperationException, necessary? >> > I want to reserve the flexibility that we may not be able to get key > size from a hardware device. Yes, the exception are not thrown in our > implementation. > > BTW, I will change the interface name from "Lengthable" to "Measurable". Well, this is not much better. There are many things that can be measured, length, weight, duration. But at least it's a real word. > > Do you want to review more? If not, I will update the code locally and > push the changes. No more. Thanks Max > > Thanks, > Xuelei > >> Thanks >> Max >> >> [1] http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html >> >>> >>> Xuelei >>> >>>> Max >>>> >>>>> >>>>>> At least, in KeyLength::getKeySize(), I would like to see "if (key >>>>>> instanceof Lengthable)" to be the first check, and, if possible, the >>>>>> only one needed, at least for keys from providers built in JDK. >>>>>> >>>>> It's OK to check it at first. But as we also need to support other >>>>> providers, I think we'd better also check other types of instance. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>> On 01/11/2012 08:57 AM, Xuelei Fan wrote: >>>>>>> "Measurable" looks like a better name. I will update the name in the >>>>>>> next webrev after this round of code review: >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~xuelei/7106773/webrev.04/ >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>> On 1/10/2012 11:47 PM, Vincent Ryan wrote: >>>>>>>> On 01/10/12 03:19 PM, Xuelei Fan wrote: >>>>>>>>> On 1/10/2012 11:09 PM, Weijun Wang wrote: >>>>>>>>>> It's late night and I'll read it tomorrow. But can you choose another >>>>>>>>>> word instead of Lengthable? Length is not a verb. >>>>>>>>>> >>>>>>>>> ;-) The name took me a lot of time, searching by google, dictionary, and >>>>>>>>> any possible English translation. I have to agree that I failed to find >>>>>>>>> a suitable name. I tried hardly to persuade myself that "lengthable" is >>>>>>>>> also used by someother application code, so it might not too bad to use >>>>>>>>> it here. >>>>>>>>> >>>>>>>>> With the word "lengthable", I want to express that the length is >>>>>>>>> measurable. Any suggestion for the better one? >>>>>>>>> >>>>>>>> >>>>>>>> Measurable ;-) >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>>>>> >>>>>>>>>> Max >>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>> ???: Xuelei Fan >>>>>>>>>> ????: 2012/1/10 22:51 >>>>>>>>>> ???: Weijun Wang >>>>>>>>>> ??: OpenJDK >>>>>>>>>> ??: Re: Code review request, 7106773: 512 bits RSA key cannot work >>>>>>>>>> withSHA384 and SHA512 >>>>>>>>>> >>>>>>>>>> It has been around 50 days passed since the last day we talked about the >>>>>>>>>> issue. Hope you can recall it from the deep memory. ;-) >>>>>>>>>> >>>>>>>>>> webrev: http://javaweb.us.oracle.com/~xufan/bugbios/7106773/webrev.04/ >>>>>>>>>> >>>>>>>>>> In this update, as we agreed, a new Oracle private interface was >>>>>>>>>> introduced: sun.security.util.Lengthable, and Lengthable.length() is >>>>>>>>>> defined to get the length an object. sun.security.pkcs11.P11Key and >>>>>>>>>> sun.security.mscapi.Key will implements the interface. As will easy and >>>>>>>>>> speedup (comparing with reflection approach) the getting of key length >>>>>>>>>> of those unextractable keys in hardware device. >>>>>>>>>> >>>>>>>>>> In the webrev, I should also include another two signed jars, >>>>>>>>>> sunpkcs11.jar and sunmscapi.jar. I will include them when I get the >>>>>>>>>> official signed jars. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Xuelei >>>>>>>>>> >>>>>>>>>> On 11/22/2011 8:41 AM, Weijun Wang wrote: >>>>>>>>>>> I really like this one. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>>>> On 11/21/2011 08:05 PM, Xuelei Fan wrote: >>>>>>>>>>>>>> How about this approach? This looks very safe. >>>>>>>>>>>>>> >>>>>>>>>>>> I also prefer this approach, although it need more updates in PKCS11 and >>>>>>>>>>>> MSCPI source code. If you vote for this approach, I will try to >>>>>>>>>>>> implement it. >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> > From xuelei.fan at oracle.com Wed Jan 11 12:12:17 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 11 Jan 2012 20:12:17 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work withSHA384 and SHA512 In-Reply-To: <4F0D7C10.6020305@oracle.com> References: <4F0C5704.9040405@oracle.com> <4F0C5D9B.8070303@oracle.com> <4F0CDE72.50408@oracle.com> <4F0D5B7D.4080909@oracle.com> <4F0D5E2C.5040906@oracle.com> <4F0D67AC.5060102@oracle.com> <4F0D6AB3.9030705@oracle.com> <4F0D6EB6.5080606@oracle.com> <4F0D75A8.6070108@oracle.com> <4F0D7C10.6020305@oracle.com> Message-ID: <4F0D7CA1.2070101@oracle.com> On 1/11/2012 8:09 PM, Weijun Wang wrote: >> > BTW, I will change the interface name from "Lengthable" to "Measurable". > Well, this is not much better. There are many things that can be > measured, length, weight, duration. But at least it's a real word. > I still hesitate to use "Measurable". How about "LengthMeasurable"? Xuelei From weijun.wang at oracle.com Wed Jan 11 12:14:05 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 11 Jan 2012 20:14:05 +0800 Subject: Code review request, 7106773: 512 bits RSA key cannot work withSHA384 and SHA512 In-Reply-To: <4F0D7CA1.2070101@oracle.com> References: <4F0C5704.9040405@oracle.com> <4F0C5D9B.8070303@oracle.com> <4F0CDE72.50408@oracle.com> <4F0D5B7D.4080909@oracle.com> <4F0D5E2C.5040906@oracle.com> <4F0D67AC.5060102@oracle.com> <4F0D6AB3.9030705@oracle.com> <4F0D6EB6.5080606@oracle.com> <4F0D75A8.6070108@oracle.com> <4F0D7C10.6020305@oracle.com> <4F0D7CA1.2070101@oracle.com> Message-ID: <4F0D7D0D.9070003@oracle.com> This is better, at least more precise. On 01/11/2012 08:12 PM, Xuelei Fan wrote: > On 1/11/2012 8:09 PM, Weijun Wang wrote: >>>> BTW, I will change the interface name from "Lengthable" to "Measurable". >> Well, this is not much better. There are many things that can be >> measured, length, weight, duration. But at least it's a real word. >> > I still hesitate to use "Measurable". How about "LengthMeasurable"? > > Xuelei > From chris.hegarty at oracle.com Wed Jan 11 13:04:07 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 11 Jan 2012 13:04:07 +0000 Subject: hg: jdk8/tl/jdk: 7128648: HttpURLConnection.getHeaderFields should return an unmodifiable Map Message-ID: <20120111130426.417554791A@hg.openjdk.java.net> Changeset: 31a1fc60a895 Author: chegar Date: 2012-01-11 10:52 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31a1fc60a895 7128648: HttpURLConnection.getHeaderFields should return an unmodifiable Map Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/HttpURLConnection/UnmodifiableMaps.java From alan.bateman at oracle.com Wed Jan 11 13:07:57 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 11 Jan 2012 13:07:57 +0000 Subject: hg: jdk8/tl/jdk: 7068856: (fs) Typo in Files.isSameFile() javadoc; ... Message-ID: <20120111130807.33E614791B@hg.openjdk.java.net> Changeset: 82144054d2d8 Author: alanb Date: 2012-01-11 13:07 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82144054d2d8 7068856: (fs) Typo in Files.isSameFile() javadoc 7099208: (fs) Files.newBufferedReader has typo in javadoc Reviewed-by: forax ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java From sean.mullan at oracle.com Wed Jan 11 16:24:39 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 11 Jan 2012 11:24:39 -0500 Subject: Code review request, 7106773: 512 bits RSA key cannot work withSHA384 and SHA512 In-Reply-To: <4F0D7D0D.9070003@oracle.com> References: <4F0C5704.9040405@oracle.com> <4F0C5D9B.8070303@oracle.com> <4F0CDE72.50408@oracle.com> <4F0D5B7D.4080909@oracle.com> <4F0D5E2C.5040906@oracle.com> <4F0D67AC.5060102@oracle.com> <4F0D6AB3.9030705@oracle.com> <4F0D6EB6.5080606@oracle.com> <4F0D75A8.6070108@oracle.com> <4F0D7C10.6020305@oracle.com> <4F0D7CA1.2070101@oracle.com> <4F0D7D0D.9070003@oracle.com> Message-ID: <4F0DB7C7.8030803@oracle.com> I think you might be trying too hard to find a word that fits the "-able" naming convention for one-method interfaces (Iterable, Callable, etc), but perhaps that is unreasonable in this case. You could simply call it Length: public interface Length { int length(); } --Sean On 1/11/12 7:14 AM, Weijun Wang wrote: > This is better, at least more precise. > > On 01/11/2012 08:12 PM, Xuelei Fan wrote: >> On 1/11/2012 8:09 PM, Weijun Wang wrote: >>>>> BTW, I will change the interface name from "Lengthable" to "Measurable". >>> Well, this is not much better. There are many things that can be >>> measured, length, weight, duration. But at least it's a real word. >>> >> I still hesitate to use "Measurable". How about "LengthMeasurable"? >> >> Xuelei >> From kumar.x.srinivasan at oracle.com Wed Jan 11 17:07:53 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 11 Jan 2012 17:07:53 +0000 Subject: hg: jdk8/tl/jdk: 7125442: jar application located in two bytes character named folder cannot be run with JRE 7 u1/u2 Message-ID: <20120111170810.E146B47923@hg.openjdk.java.net> Changeset: 96fe796fd242 Author: ksrini Date: 2012-01-11 08:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/96fe796fd242 7125442: jar application located in two bytes character named folder cannot be run with JRE 7 u1/u2 Reviewed-by: sherman, mchung, darcy ! src/share/bin/java.c + test/tools/launcher/I18NJarTest.java ! test/tools/launcher/TestHelper.java From maurizio.cimadamore at oracle.com Wed Jan 11 18:25:45 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 11 Jan 2012 18:25:45 +0000 Subject: hg: jdk8/tl/langtools: 7126754: Generics compilation failure casting List to List Message-ID: <20120111182549.7716F47925@hg.openjdk.java.net> Changeset: 70d92518063e Author: mcimadamore Date: 2012-01-11 18:23 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/70d92518063e 7126754: Generics compilation failure casting List to List Summary: Problems with Types.rewriteQuantifiers not preserving variance Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/7126754/T7126754.java + test/tools/javac/cast/7126754/T7126754.out From valerie.peng at oracle.com Wed Jan 11 23:16:40 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Wed, 11 Jan 2012 15:16:40 -0800 Subject: code review request: 7118809: rcache deadlock In-Reply-To: <4F0BCF7C.4060400@oracle.com> References: <7296394.1325559670063.JavaMail.sbladm@swsblss4-new> <4F0BCF7C.4060400@oracle.com> Message-ID: <4F0E1858.8050106@oracle.com> Max, Well, now that you removed the call of "table.remove(principal)", the "table" field in ReplayCache is useless. Given that both classes are serializable, I understand that we may not able to do as much clean up as we want. Now that you removed the "table.remove(principal)" call from the ReplayCache class, I think we should update the CacheTable.put(...) method as well since Its "super.put(principal, rc)" call is now redundant given that there is no chance for ReplayCache to remove the entry. In addition, I think the CacheTable.put(...) method should check if the ReplayCache object is empty and if yes, do the removal itself. So, the cleanup of empty ReplayCache object is still done, except it's now in CacheTable class instead of ReplayCache class which leads to the deadlock. Lastly, not really relevant to your changes here, but the code in both classes doesn't seem too efficient and some even looks not quite correct. For example, the impl of ReplayCache.put(...) method first goes through the LinkList and insert authenticator timestamp in descending order and then going through it again removing the expired timestamps. Wouldn't it be better to revert the order or doing both together, i.e. check for expiration and find the indexing while going through the list once? Thanks, Valerie On 01/09/12 21:41, Weijun Wang wrote: > Hi Valerie > > Please review my fix: > > http://cr.openjdk.java.net/~weijun/7118809/webrev.00/ > > Basically, CacheTable.put() operates on ReplayCache inside it, and > ReplayCache.put() operates on CacheTable containing it, and both > methods are synchronized and using thread-safe Hashtable. > > My solution is to move the "table.remove(principal)" line in > ReplayCache.put() outside the method. I search thru JDK and > CacheTable.put() is the only place the method is called: > > public synchronized void put(String principal, AuthTime time, long > currTime) { > ReplayCache rc = super.get(principal); > if (rc == null) { > if (DEBUG) { > System.out.println("replay cache for " + principal + " > is null."); > } > rc = new ReplayCache(principal, this); > rc.put(time, currTime); > super.put(principal, rc); > } > else { > rc.put(time, currTime); > // re-insert the entry, since rc.put could have removed > the entry > super.put(principal, rc); > if (DEBUG) { > System.out.println("replay cache found."); > } > } > } > > Curiously, you can see after each call, the ReplayCache object is > added back into the CacheTable. Therefore, the remove action is useless. > > Maybe the most correct way is to remove a ReplayCache from a > CacheTable if it's empty, but that re-insert line was added in a > security fix some years ago which I cannot decipher. > > So my fix simply removes the "remove" call in ReplayCache. > > No regression test, hard to reproduce failure. > > Thanks > Max > > -------- Original Message -------- > *Change Request ID*: 7118809 > *Synopsis*: rcache deadlock > > === *Description* > ============================================================ > A DESCRIPTION OF THE PROBLEM : > The program as below: > -------------------------------------------------- > import sun.security.krb5.internal.rcache.*; > import sun.security.krb5.internal.*; > import java.util.*; > > public class KTest2 { > public static void main(String [] a) throws Exception{ > final CacheTable ct = new CacheTable(); > final long time = System.currentTimeMillis(); > ct.put("TheOnlyOne", new AuthTime( time - > Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * 1000L, 0), time); > final ReplayCache rc = (ReplayCache) ct.get("TheOnlyOne"); > new Thread() { > public void run() { > rc.put(new AuthTime( time - Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * > 1000L, 0), time + 300*1000); > } > }.start(); > ct.put("TheOnlyOne", new AuthTime( time - > Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * 1000L, 0), time); > } > } > -------------------------------------------------- > When compiles as in: javac KTest2.java > and executed as in: java KTest2 > can deadlock the hosting JVM as is reproduced by the stack-trace dump, > below: > ------------------------------------------------- > Found one Java-level deadlock: > ============================= > "Thread-0": > waiting to lock monitor 0x0921d720 (object 0xa5621b80, a > sun.security.krb5.internal.rcache.CacheTable), > which is held by "main" > "main": > waiting to lock monitor 0x0921caa0 (object 0xa5622fb8, a > sun.security.krb5.internal.rcache.ReplayCache), > which is held by "Thread-0" > > Java stack information for the threads listed above: > =================================================== > "Thread-0": > at java.util.Hashtable.remove(Hashtable.java:435) > - waiting to lock <0xa5621b80> (a > sun.security.krb5.internal.rcache.CacheTable) > at > sun.security.krb5.internal.rcache.ReplayCache.put(ReplayCache.java:123) > - locked <0xa5622fb8> (a > sun.security.krb5.internal.rcache.ReplayCache) > at KTest2$1.run(KTest2.java:13) > "main": > at > sun.security.krb5.internal.rcache.ReplayCache.put(ReplayCache.java:62) > - waiting to lock <0xa5622fb8> (a > sun.security.krb5.internal.rcache.ReplayCache) > at > sun.security.krb5.internal.rcache.CacheTable.put(CacheTable.java:59) > - locked <0xa5621b80> (a > sun.security.krb5.internal.rcache.CacheTable) > at KTest2.main(KTest2.java:16) > > Found 1 deadlock. > ... > From valerie.peng at oracle.com Thu Jan 12 01:04:57 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Wed, 11 Jan 2012 17:04:57 -0800 Subject: 7u Code review request for 7033170, 7092821, 7092825 In-Reply-To: <4EF248F6.3080000@oracle.com> References: <4EF1157C.7030506@oracle.com> <4EF23034.8030208@oracle.com> <4EF248F6.3080000@oracle.com> Message-ID: <4F0E31B9.8040609@oracle.com> Sean, I need to backport 7033170 to 7u4. It's the exact same set of changes that you've reviewed for JDK8. Also, performance team find some performance bottlenecks when running against SPECjvm and requested the 2 performance bugs be addressed for 7u4. I've made slight changes to what they suggested and applied them to both JDK8 and 7u. Can you please take a look? 7033170: Cipher.getMaxAllowedKeyLength(String) throws NoSuchAlgorithmException jdk7u Weberv: http://cr.openjdk.java.net/~valeriep/7033170_7u/ 7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck. jdk7u Webrev: http://cr.openjdk.java.net/~valeriep/7092821_7u/ jdk8 Webrev: http://cr.openjdk.java.net/~valeriep/7092821/ 7092825: javax.crypto.Cipher.Transform.patternCache is synchronizedMap and became scalability bottleneck. jdk7u Webrev: http://cr.openjdk.java.net/~valeriep/7092825_7u/ jdk8 Webrev: http://cr.openjdk.java.net/~valeriep/7092825/ Thanks, Valerie From schlosna at gmail.com Thu Jan 12 05:48:10 2012 From: schlosna at gmail.com (David Schlosnagle) Date: Thu, 12 Jan 2012 00:48:10 -0500 Subject: 7u Code review request for 7033170, 7092821, 7092825 In-Reply-To: <4F0E31B9.8040609@oracle.com> References: <4EF1157C.7030506@oracle.com> <4EF23034.8030208@oracle.com> <4EF248F6.3080000@oracle.com> <4F0E31B9.8040609@oracle.com> Message-ID: On Wed, Jan 11, 2012 at 8:04 PM, Valerie (Yu-Ching) Peng wrote: > > 7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck. > jdk7u Webrev: http://cr.openjdk.java.net/~valeriep/7092821_7u/ > jdk8 Webrev: http://cr.openjdk.java.net/~valeriep/7092821/ Valerie, You might already be aware of this, but there is a data race on lines 685 - 686 of the Provider's getService(String, String) method. If there are concurrent callers to getService while lookupCache == null, the lookupCache may be overwritten by a new ConcurrentHashMap after another thread has just instantiated and populated an entry in the cache leading to thrashing on lookupCache. It might be worthwhile to either use a double checked lock to avoid the race at the expense of an additional lock and volatile read in the case lookupCache == null or add a comment indicating that this is an accepted data race. There is also now the possibility that if one thread is executing getService while another thread invokes one of the methods that sets lookupCache = null, there could then be a NullPointerException on line 703 as the volatile read would now see a null and fail. You could prevent that by either moving the putIfAbsent under the lock (not ideal for performance if you're already seeing contention), or just maintain a local reference to the cache map and use it throughout the getService method. This would mean that if the lookupCache reference was concurrently mutated, the putIfAbsent would basically be a write to the local map reference which is now garbage, but shouldn't really hurt anything. I'd propose something along the lines of the following to address this: public Service getService(String type, String algorithm) { ServiceKey key = new ServiceKey(type, algorithm); ConcurrentMap localLookupCache = getLookupCache(); Service result = localLookupCache.get(key); if (result != null) { return (result == NULL_MARK? null : result); } synchronized (this) { checkInitialized(); if (serviceMap != null) { result = serviceMap.get(key); } if (result == null) { ensureLegacyParsed(); result = (legacyMap != null) ? legacyMap.get(key) : null; } } // under concurrent mutation of lookupCache, this will write to map that is no // longer the active cache localLookupCache.putIfAbsent(key, (result == null? NULL_MARK : result)); return result; } private ConcurrentMap getLookupCache() { if (lookupCache == null) { synchronized (this) { // must fall back on double checked lock if (lookupCache == null) { lookupCache = new ConcurrentHashMap<>(); } } } return lookupCache; } - Dave For reference, here were the original changes: 429 // Cache for service lookups. Discard whenever services are changed. 430 private transient volatile ConcurrentMap lookupCache; ...snip... 682 public Service getService(String type, String algorithm) { 683 ServiceKey key = new ServiceKey(type, algorithm); 684 Service result = null; 685 if (lookupCache == null) { 686 lookupCache = new ConcurrentHashMap<>(); 687 } else { 688 result = lookupCache.get(key); 689 if (result != null) { 690 return (result == NULL_MARK? null : result); 691 } 692 } 693 synchronized (this) { 694 checkInitialized(); 695 if (serviceMap != null) { 696 result = serviceMap.get(key); 697 } 698 if (result == null) { 699 ensureLegacyParsed(); 700 result = (legacyMap != null) ? legacyMap.get(key) : null; 701 } 702 } 703 lookupCache.putIfAbsent(key, (result == null? NULL_MARK : result)); 704 return result; 705 } From weijun.wang at oracle.com Thu Jan 12 06:11:50 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 12 Jan 2012 14:11:50 +0800 Subject: code review request: 7118809: rcache deadlock In-Reply-To: <4F0E1858.8050106@oracle.com> References: <7296394.1325559670063.JavaMail.sbladm@swsblss4-new> <4F0BCF7C.4060400@oracle.com> <4F0E1858.8050106@oracle.com> Message-ID: <4F0E79A6.9060408@oracle.com> On 01/12/2012 07:16 AM, Valerie (Yu-Ching) Peng wrote: > Max, > > Well, now that you removed the call of "table.remove(principal)", the > "table" field in ReplayCache is useless. > Given that both classes are serializable, I understand that we may not > able to do as much clean up as we want. Correct. > > Now that you removed the "table.remove(principal)" call from the > ReplayCache class, I think we should update the CacheTable.put(...) > method as well since Its "super.put(principal, rc)" call is now > redundant given that there is no chance for ReplayCache to remove the entry. Correct. > > In addition, I think the CacheTable.put(...) method should check if the > ReplayCache object is empty and if yes, do the removal itself. > So, the cleanup of empty ReplayCache object is still done, except it's > now in CacheTable class instead of ReplayCache class which leads to the > deadlock. That was my original plan. But I have no idea why in CacheTable there is // re-insert the entry, since rc.put could have removed the entry Does it really have a secret use? > > Lastly, not really relevant to your changes here, but the code in both > classes doesn't seem too efficient and some even looks not quite correct. > For example, the impl of ReplayCache.put(...) method first goes through > the LinkList and insert authenticator timestamp in descending order and > then going through it again removing the expired timestamps. Wouldn't it > be better to revert the order or doing both together, i.e. check for > expiration and find the indexing while going through the list once? Maybe. Thanks Max > > Thanks, > Valerie > > On 01/09/12 21:41, Weijun Wang wrote: >> Hi Valerie >> >> Please review my fix: >> >> http://cr.openjdk.java.net/~weijun/7118809/webrev.00/ >> >> Basically, CacheTable.put() operates on ReplayCache inside it, and >> ReplayCache.put() operates on CacheTable containing it, and both >> methods are synchronized and using thread-safe Hashtable. >> >> My solution is to move the "table.remove(principal)" line in >> ReplayCache.put() outside the method. I search thru JDK and >> CacheTable.put() is the only place the method is called: >> >> public synchronized void put(String principal, AuthTime time, long >> currTime) { >> ReplayCache rc = super.get(principal); >> if (rc == null) { >> if (DEBUG) { >> System.out.println("replay cache for " + principal + " >> is null."); >> } >> rc = new ReplayCache(principal, this); >> rc.put(time, currTime); >> super.put(principal, rc); >> } >> else { >> rc.put(time, currTime); >> // re-insert the entry, since rc.put could have removed >> the entry >> super.put(principal, rc); >> if (DEBUG) { >> System.out.println("replay cache found."); >> } >> } >> } >> >> Curiously, you can see after each call, the ReplayCache object is >> added back into the CacheTable. Therefore, the remove action is useless. >> >> Maybe the most correct way is to remove a ReplayCache from a >> CacheTable if it's empty, but that re-insert line was added in a >> security fix some years ago which I cannot decipher. >> >> So my fix simply removes the "remove" call in ReplayCache. >> >> No regression test, hard to reproduce failure. >> >> Thanks >> Max >> >> -------- Original Message -------- >> *Change Request ID*: 7118809 >> *Synopsis*: rcache deadlock >> >> === *Description* >> ============================================================ >> A DESCRIPTION OF THE PROBLEM : >> The program as below: >> -------------------------------------------------- >> import sun.security.krb5.internal.rcache.*; >> import sun.security.krb5.internal.*; >> import java.util.*; >> >> public class KTest2 { >> public static void main(String [] a) throws Exception{ >> final CacheTable ct = new CacheTable(); >> final long time = System.currentTimeMillis(); >> ct.put("TheOnlyOne", new AuthTime( time - >> Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * 1000L, 0), time); >> final ReplayCache rc = (ReplayCache) ct.get("TheOnlyOne"); >> new Thread() { >> public void run() { >> rc.put(new AuthTime( time - Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * >> 1000L, 0), time + 300*1000); >> } >> }.start(); >> ct.put("TheOnlyOne", new AuthTime( time - >> Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * 1000L, 0), time); >> } >> } >> -------------------------------------------------- >> When compiles as in: javac KTest2.java >> and executed as in: java KTest2 >> can deadlock the hosting JVM as is reproduced by the stack-trace dump, >> below: >> ------------------------------------------------- >> Found one Java-level deadlock: >> ============================= >> "Thread-0": >> waiting to lock monitor 0x0921d720 (object 0xa5621b80, a >> sun.security.krb5.internal.rcache.CacheTable), >> which is held by "main" >> "main": >> waiting to lock monitor 0x0921caa0 (object 0xa5622fb8, a >> sun.security.krb5.internal.rcache.ReplayCache), >> which is held by "Thread-0" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-0": >> at java.util.Hashtable.remove(Hashtable.java:435) >> - waiting to lock<0xa5621b80> (a >> sun.security.krb5.internal.rcache.CacheTable) >> at >> sun.security.krb5.internal.rcache.ReplayCache.put(ReplayCache.java:123) >> - locked<0xa5622fb8> (a >> sun.security.krb5.internal.rcache.ReplayCache) >> at KTest2$1.run(KTest2.java:13) >> "main": >> at >> sun.security.krb5.internal.rcache.ReplayCache.put(ReplayCache.java:62) >> - waiting to lock<0xa5622fb8> (a >> sun.security.krb5.internal.rcache.ReplayCache) >> at >> sun.security.krb5.internal.rcache.CacheTable.put(CacheTable.java:59) >> - locked<0xa5621b80> (a >> sun.security.krb5.internal.rcache.CacheTable) >> at KTest2.main(KTest2.java:16) >> >> Found 1 deadlock. >> ... >> > From schlosna at gmail.com Thu Jan 12 06:28:46 2012 From: schlosna at gmail.com (David Schlosnagle) Date: Thu, 12 Jan 2012 01:28:46 -0500 Subject: 7u Code review request for 7033170, 7092821, 7092825 In-Reply-To: References: <4EF1157C.7030506@oracle.com> <4EF23034.8030208@oracle.com> <4EF248F6.3080000@oracle.com> <4F0E31B9.8040609@oracle.com> Message-ID: On Thu, Jan 12, 2012 at 12:48 AM, David Schlosnagle wrote: > ? ?private ConcurrentMap getLookupCache() { > ? ? ? ?if (lookupCache == null) { > ? ? ? ? ? ?synchronized (this) { > ? ? ? ? ? ? ? ?// must fall back on double checked lock > ? ? ? ? ? ? ? ?if (lookupCache == null) { > ? ? ? ? ? ? ? ? ? ?lookupCache = new ConcurrentHashMap<>(); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > ? ? ? ?return lookupCache; > ? ?} Slight correction to the previous suggested getLookupCache() method as there was still the possibility that when interleaved methods that set lookupCache = null would result in getLookupCache() returning null and trigger NPE in getService: private ConcurrentMap getLookupCache() { ConcurrentMap localLookupCache = lookupCache; if (localLookupCache == null) { // must fall back on double checked lock synchronized (this) { if (lookupCache == null) { localLookupCache = new ConcurrentHashMap<>(); lookupCache = localLookupCache; } } } return localLookupCache; } - Dave From xuelei.fan at oracle.com Thu Jan 12 11:40:18 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Thu, 12 Jan 2012 11:40:18 +0000 Subject: hg: jdk8/tl/jdk: 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 Message-ID: <20120112114046.B5E6A47939@hg.openjdk.java.net> Changeset: 11e52d5ba64e Author: xuelei Date: 2012-01-12 03:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11e52d5ba64e 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java + src/share/classes/sun/security/util/KeyLength.java + src/share/classes/sun/security/util/Length.java ! src/windows/classes/sun/security/mscapi/Key.java ! src/windows/classes/sun/security/mscapi/RSACipher.java ! src/windows/classes/sun/security/mscapi/RSASignature.java + test/sun/security/mscapi/ShortRSAKey1024.sh + test/sun/security/mscapi/ShortRSAKey512.sh + test/sun/security/mscapi/ShortRSAKey768.sh + test/sun/security/mscapi/ShortRSAKeyWithinTLS.java ! test/sun/security/pkcs11/KeyStore/ClientAuth.java ! test/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java + test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java From xuelei.fan at oracle.com Thu Jan 12 15:17:07 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 Jan 2012 23:17:07 +0800 Subject: Code review request, CR 7093640 Enable TLS 1.1 and TLS 1.2 by default in JSSE client Message-ID: <4F0EF973.90503@oracle.com> Hi, webrev: http://cr.openjdk.java.net/~xuelei/7093640/webrev.00/ It's time to enable TLS 1.1 and TLS 1.2 in JDK by default. There is a known tls-version-number tolerant issue for deployed SSL servers. That is, some servers cannot work with clients whose TLS version number is bigger than or equals to TLS 1.0. It only happens to very very very very old and few servers now. In JDK 7, because of known server tls-version-number tolerant issues , TLS 1.1 and TLS 1.2 is not enabled by default in JSSE client. TLS 1.1 is able to avoid the CBC issues in TLS 1.0 and previous releases; and TLS 1.2 is able to use stronger hash functions. As the tls-version-number tolerant issues have been decreasing recent years, and the industry is purchasing to use new TLS versions in order to avoid CBC attack and comply to new hash policy, it's time for us to consider enable TLS 1.1 and TLS 1.2 in JSSE client by default. I know that because there are a few very old servers refuse to or cannot upgrade to latest TLS implementations, we may run into a few compatibility issue because of TLS-version-number tolerant issues. But what's the right time to make use of the advanced features for most of us? It's time to enable TLS 1.1 and TLS 1.2 in JDK by default. Please review the the changes. Thanks, Xuelei From maurizio.cimadamore at oracle.com Thu Jan 12 15:29:13 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 12 Jan 2012 15:29:13 +0000 Subject: hg: jdk8/tl/langtools: 7123100: javac fails with java.lang.StackOverflowError Message-ID: <20120112152917.CB5DB4793E@hg.openjdk.java.net> Changeset: 133744729455 Author: mcimadamore Date: 2012-01-12 15:28 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/133744729455 7123100: javac fails with java.lang.StackOverflowError Summary: Inference of under-constrained type-variables creates erroneous recursive wildcard types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/cast/7123100/T7123100a.java + test/tools/javac/cast/7123100/T7123100a.out + test/tools/javac/cast/7123100/T7123100b.java + test/tools/javac/cast/7123100/T7123100b.out + test/tools/javac/cast/7123100/T7123100c.java + test/tools/javac/cast/7123100/T7123100c.out + test/tools/javac/cast/7123100/T7123100d.java + test/tools/javac/cast/7123100/T7123100d.out From sean.mullan at oracle.com Thu Jan 12 16:04:00 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 12 Jan 2012 11:04:00 -0500 Subject: code review request: 7090565: Move test/closed/javax/security/auth/x500/X500Principal/Parse.java to open tests In-Reply-To: <4F0D415C.3000706@oracle.com> References: <22706477.1316049657228.JavaMail.sbladm@swsblss4-new> <4F0D415C.3000706@oracle.com> Message-ID: <4F0F0470.4080209@oracle.com> Hi Max, Looks fine. I assume you will also remove the corresponding files from the closed repo? --Sean On 1/11/12 2:59 AM, Weijun Wang wrote: > Hi Sean > > Webrev at > > http://cr.openjdk.java.net/~weijun/7090565/webrev.00/ > > I changed the name to "duke test", and inline a binary file as a byte > array (lines 93-99). > > Thanks > Max > > -------- Original Message -------- > > *Change Request ID*: 7090565 > *Synopsis*: Move > test/closed/javax/security/auth/x500/X500Principal/Parse.java to open tests > > > === *Description* > ============================================================ > We should see if it is feasible to move > test/closed/javax/security/auth/x500/X500Principal/Parse.java to the > open area. It contains tests for several bugs, none of which are > vulnerabilities. > From valerie.peng at oracle.com Thu Jan 12 23:06:35 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 12 Jan 2012 15:06:35 -0800 Subject: 7u Code review request for 7033170, 7092821, 7092825 In-Reply-To: References: <4EF1157C.7030506@oracle.com> <4EF23034.8030208@oracle.com> <4EF248F6.3080000@oracle.com> <4F0E31B9.8040609@oracle.com> Message-ID: <4F0F677B.4090406@oracle.com> Dave, Thanks for the comments. Let me think about it some more and see how to better address this kind of racing issue. If you have concerns on fixes for 7033170 and 7092825, please let me know. Sean, Can you please ignore the review request for 7092821 for now. I'll send out an updated version later. If you can still review the remaining two, that'd be great. Thanks, Valerie On 01/11/12 21:48, David Schlosnagle wrote: > On Wed, Jan 11, 2012 at 8:04 PM, Valerie (Yu-Ching) Peng > wrote: >> 7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck. >> jdk7u Webrev: http://cr.openjdk.java.net/~valeriep/7092821_7u/ >> jdk8 Webrev: http://cr.openjdk.java.net/~valeriep/7092821/ > Valerie, > > You might already be aware of this, but there is a data race on lines > 685 - 686 of the Provider's getService(String, String) method. If > there are concurrent callers to getService while lookupCache == null, > the lookupCache may be overwritten by a new ConcurrentHashMap after > another thread has just instantiated and populated an entry in the > cache leading to thrashing on lookupCache. It might be worthwhile to > either use a double checked lock to avoid the race at the expense of > an additional lock and volatile read in the case lookupCache == null > or add a comment indicating that this is an accepted data race. > > There is also now the possibility that if one thread is executing > getService while another thread invokes one of the methods that sets > lookupCache = null, there could then be a NullPointerException on line > 703 as the volatile read would now see a null and fail. You could > prevent that by either moving the putIfAbsent under the lock (not > ideal for performance if you're already seeing contention), or just > maintain a local reference to the cache map and use it throughout the > getService method. This would mean that if the lookupCache reference > was concurrently mutated, the putIfAbsent would basically be a write > to the local map reference which is now garbage, but shouldn't really > hurt anything. > > I'd propose something along the lines of the following to address this: > > public Service getService(String type, String algorithm) { > ServiceKey key = new ServiceKey(type, algorithm); > ConcurrentMap localLookupCache = getLookupCache(); > Service result = localLookupCache.get(key); > if (result != null) { > return (result == NULL_MARK? null : result); > } > synchronized (this) { > checkInitialized(); > if (serviceMap != null) { > result = serviceMap.get(key); > } > if (result == null) { > ensureLegacyParsed(); > result = (legacyMap != null) ? legacyMap.get(key) : null; > } > } > // under concurrent mutation of lookupCache, this will write > to map that is no > // longer the active cache > localLookupCache.putIfAbsent(key, (result == null? NULL_MARK : result)); > return result; > } > > private ConcurrentMap getLookupCache() { > if (lookupCache == null) { > synchronized (this) { > // must fall back on double checked lock > if (lookupCache == null) { > lookupCache = new ConcurrentHashMap<>(); > } > } > } > return lookupCache; > } > > > - Dave > > > For reference, here were the original changes: > 429 // Cache for service lookups. Discard whenever services are changed. > 430 private transient volatile ConcurrentMap > lookupCache; > ...snip... > 682 public Service getService(String type, String algorithm) { > 683 ServiceKey key = new ServiceKey(type, algorithm); > 684 Service result = null; > 685 if (lookupCache == null) { > 686 lookupCache = new ConcurrentHashMap<>(); > 687 } else { > 688 result = lookupCache.get(key); > 689 if (result != null) { > 690 return (result == NULL_MARK? null : result); > 691 } > 692 } > 693 synchronized (this) { > 694 checkInitialized(); > 695 if (serviceMap != null) { > 696 result = serviceMap.get(key); > 697 } > 698 if (result == null) { > 699 ensureLegacyParsed(); > 700 result = (legacyMap != null) ? legacyMap.get(key) : null; > 701 } > 702 } > 703 lookupCache.putIfAbsent(key, (result == null? NULL_MARK : result)); > 704 return result; > 705 } From valerie.peng at oracle.com Thu Jan 12 23:20:02 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 12 Jan 2012 15:20:02 -0800 Subject: code review request: 7118809: rcache deadlock In-Reply-To: <4F0E79A6.9060408@oracle.com> References: <7296394.1325559670063.JavaMail.sbladm@swsblss4-new> <4F0BCF7C.4060400@oracle.com> <4F0E1858.8050106@oracle.com> <4F0E79A6.9060408@oracle.com> Message-ID: <4F0F6AA2.1030801@oracle.com> Secret use? As far as I can see, the CacheTable.put(...) method handles the case where an ReplayCache object isn't found and I can't think of any secret use for this. It looks to me that cleaning this up is only an internal impl of CacheTable class and should not affect its behavior. Removing an empty Cache seems more correct than leaving it there. Thanks, Valerie On 01/11/12 22:11, Weijun Wang wrote: >> In addition, I think the CacheTable.put(...) method should check if the >> ReplayCache object is empty and if yes, do the removal itself. >> So, the cleanup of empty ReplayCache object is still done, except it's >> now in CacheTable class instead of ReplayCache class which leads to the >> deadlock. > > That was my original plan. But I have no idea why in CacheTable there is > > // re-insert the entry, since rc.put could have removed the entry > > Does it really have a secret use? > >> >> Lastly, not really relevant to your changes here, but the code in both >> classes doesn't seem too efficient and some even looks not quite >> correct. >> For example, the impl of ReplayCache.put(...) method first goes through >> the LinkList and insert authenticator timestamp in descending order and >> then going through it again removing the expired timestamps. Wouldn't it >> be better to revert the order or doing both together, i.e. check for >> expiration and find the indexing while going through the list once? > > Maybe. > > Thanks > Max > >> >> Thanks, >> Valerie >> >> On 01/09/12 21:41, Weijun Wang wrote: >>> Hi Valerie >>> >>> Please review my fix: >>> >>> http://cr.openjdk.java.net/~weijun/7118809/webrev.00/ >>> >>> Basically, CacheTable.put() operates on ReplayCache inside it, and >>> ReplayCache.put() operates on CacheTable containing it, and both >>> methods are synchronized and using thread-safe Hashtable. >>> >>> My solution is to move the "table.remove(principal)" line in >>> ReplayCache.put() outside the method. I search thru JDK and >>> CacheTable.put() is the only place the method is called: >>> >>> public synchronized void put(String principal, AuthTime time, long >>> currTime) { >>> ReplayCache rc = super.get(principal); >>> if (rc == null) { >>> if (DEBUG) { >>> System.out.println("replay cache for " + principal + " >>> is null."); >>> } >>> rc = new ReplayCache(principal, this); >>> rc.put(time, currTime); >>> super.put(principal, rc); >>> } >>> else { >>> rc.put(time, currTime); >>> // re-insert the entry, since rc.put could have removed >>> the entry >>> super.put(principal, rc); >>> if (DEBUG) { >>> System.out.println("replay cache found."); >>> } >>> } >>> } >>> >>> Curiously, you can see after each call, the ReplayCache object is >>> added back into the CacheTable. Therefore, the remove action is >>> useless. >>> >>> Maybe the most correct way is to remove a ReplayCache from a >>> CacheTable if it's empty, but that re-insert line was added in a >>> security fix some years ago which I cannot decipher. >>> >>> So my fix simply removes the "remove" call in ReplayCache. >>> >>> No regression test, hard to reproduce failure. >>> >>> Thanks >>> Max >>> >>> -------- Original Message -------- >>> *Change Request ID*: 7118809 >>> *Synopsis*: rcache deadlock >>> >>> === *Description* >>> ============================================================ >>> A DESCRIPTION OF THE PROBLEM : >>> The program as below: >>> -------------------------------------------------- >>> import sun.security.krb5.internal.rcache.*; >>> import sun.security.krb5.internal.*; >>> import java.util.*; >>> >>> public class KTest2 { >>> public static void main(String [] a) throws Exception{ >>> final CacheTable ct = new CacheTable(); >>> final long time = System.currentTimeMillis(); >>> ct.put("TheOnlyOne", new AuthTime( time - >>> Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * 1000L, 0), time); >>> final ReplayCache rc = (ReplayCache) ct.get("TheOnlyOne"); >>> new Thread() { >>> public void run() { >>> rc.put(new AuthTime( time - Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * >>> 1000L, 0), time + 300*1000); >>> } >>> }.start(); >>> ct.put("TheOnlyOne", new AuthTime( time - >>> Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * 1000L, 0), time); >>> } >>> } >>> -------------------------------------------------- >>> When compiles as in: javac KTest2.java >>> and executed as in: java KTest2 >>> can deadlock the hosting JVM as is reproduced by the stack-trace dump, >>> below: >>> ------------------------------------------------- >>> Found one Java-level deadlock: >>> ============================= >>> "Thread-0": >>> waiting to lock monitor 0x0921d720 (object 0xa5621b80, a >>> sun.security.krb5.internal.rcache.CacheTable), >>> which is held by "main" >>> "main": >>> waiting to lock monitor 0x0921caa0 (object 0xa5622fb8, a >>> sun.security.krb5.internal.rcache.ReplayCache), >>> which is held by "Thread-0" >>> >>> Java stack information for the threads listed above: >>> =================================================== >>> "Thread-0": >>> at java.util.Hashtable.remove(Hashtable.java:435) >>> - waiting to lock<0xa5621b80> (a >>> sun.security.krb5.internal.rcache.CacheTable) >>> at >>> sun.security.krb5.internal.rcache.ReplayCache.put(ReplayCache.java:123) >>> - locked<0xa5622fb8> (a >>> sun.security.krb5.internal.rcache.ReplayCache) >>> at KTest2$1.run(KTest2.java:13) >>> "main": >>> at >>> sun.security.krb5.internal.rcache.ReplayCache.put(ReplayCache.java:62) >>> - waiting to lock<0xa5622fb8> (a >>> sun.security.krb5.internal.rcache.ReplayCache) >>> at >>> sun.security.krb5.internal.rcache.CacheTable.put(CacheTable.java:59) >>> - locked<0xa5621b80> (a >>> sun.security.krb5.internal.rcache.CacheTable) >>> at KTest2.main(KTest2.java:16) >>> >>> Found 1 deadlock. >>> ... >>> >> From weijun.wang at oracle.com Fri Jan 13 01:46:50 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 13 Jan 2012 09:46:50 +0800 Subject: code review request: 7118809: rcache deadlock In-Reply-To: <4F0F6AA2.1030801@oracle.com> References: <7296394.1325559670063.JavaMail.sbladm@swsblss4-new> <4F0BCF7C.4060400@oracle.com> <4F0E1858.8050106@oracle.com> <4F0E79A6.9060408@oracle.com> <4F0F6AA2.1030801@oracle.com> Message-ID: <4F0F8D0A.2080501@oracle.com> How about this? We remove the empty ReplayCache in JDK 8 but keep it in 7u4 (I want to backport it). I just feel there is a hidden monster somewhere. Thanks Max On 01/13/2012 07:20 AM, Valerie (Yu-Ching) Peng wrote: > > Secret use? > As far as I can see, the CacheTable.put(...) method handles the case > where an ReplayCache object isn't found and I can't think of any secret > use for this. > It looks to me that cleaning this up is only an internal impl of > CacheTable class and should not affect its behavior. > Removing an empty Cache seems more correct than leaving it there. > Thanks, > Valerie > > On 01/11/12 22:11, Weijun Wang wrote: >>> In addition, I think the CacheTable.put(...) method should check if the >>> ReplayCache object is empty and if yes, do the removal itself. >>> So, the cleanup of empty ReplayCache object is still done, except it's >>> now in CacheTable class instead of ReplayCache class which leads to the >>> deadlock. >> >> That was my original plan. But I have no idea why in CacheTable there is >> >> // re-insert the entry, since rc.put could have removed the entry >> >> Does it really have a secret use? >> >>> >>> Lastly, not really relevant to your changes here, but the code in both >>> classes doesn't seem too efficient and some even looks not quite >>> correct. >>> For example, the impl of ReplayCache.put(...) method first goes through >>> the LinkList and insert authenticator timestamp in descending order and >>> then going through it again removing the expired timestamps. Wouldn't it >>> be better to revert the order or doing both together, i.e. check for >>> expiration and find the indexing while going through the list once? >> >> Maybe. >> >> Thanks >> Max >> >>> >>> Thanks, >>> Valerie >>> >>> On 01/09/12 21:41, Weijun Wang wrote: >>>> Hi Valerie >>>> >>>> Please review my fix: >>>> >>>> http://cr.openjdk.java.net/~weijun/7118809/webrev.00/ >>>> >>>> Basically, CacheTable.put() operates on ReplayCache inside it, and >>>> ReplayCache.put() operates on CacheTable containing it, and both >>>> methods are synchronized and using thread-safe Hashtable. >>>> >>>> My solution is to move the "table.remove(principal)" line in >>>> ReplayCache.put() outside the method. I search thru JDK and >>>> CacheTable.put() is the only place the method is called: >>>> >>>> public synchronized void put(String principal, AuthTime time, long >>>> currTime) { >>>> ReplayCache rc = super.get(principal); >>>> if (rc == null) { >>>> if (DEBUG) { >>>> System.out.println("replay cache for " + principal + " >>>> is null."); >>>> } >>>> rc = new ReplayCache(principal, this); >>>> rc.put(time, currTime); >>>> super.put(principal, rc); >>>> } >>>> else { >>>> rc.put(time, currTime); >>>> // re-insert the entry, since rc.put could have removed >>>> the entry >>>> super.put(principal, rc); >>>> if (DEBUG) { >>>> System.out.println("replay cache found."); >>>> } >>>> } >>>> } >>>> >>>> Curiously, you can see after each call, the ReplayCache object is >>>> added back into the CacheTable. Therefore, the remove action is >>>> useless. >>>> >>>> Maybe the most correct way is to remove a ReplayCache from a >>>> CacheTable if it's empty, but that re-insert line was added in a >>>> security fix some years ago which I cannot decipher. >>>> >>>> So my fix simply removes the "remove" call in ReplayCache. >>>> >>>> No regression test, hard to reproduce failure. >>>> >>>> Thanks >>>> Max >>>> >>>> -------- Original Message -------- >>>> *Change Request ID*: 7118809 >>>> *Synopsis*: rcache deadlock >>>> >>>> === *Description* >>>> ============================================================ >>>> A DESCRIPTION OF THE PROBLEM : >>>> The program as below: >>>> -------------------------------------------------- >>>> import sun.security.krb5.internal.rcache.*; >>>> import sun.security.krb5.internal.*; >>>> import java.util.*; >>>> >>>> public class KTest2 { >>>> public static void main(String [] a) throws Exception{ >>>> final CacheTable ct = new CacheTable(); >>>> final long time = System.currentTimeMillis(); >>>> ct.put("TheOnlyOne", new AuthTime( time - >>>> Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * 1000L, 0), time); >>>> final ReplayCache rc = (ReplayCache) ct.get("TheOnlyOne"); >>>> new Thread() { >>>> public void run() { >>>> rc.put(new AuthTime( time - Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * >>>> 1000L, 0), time + 300*1000); >>>> } >>>> }.start(); >>>> ct.put("TheOnlyOne", new AuthTime( time - >>>> Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * 1000L, 0), time); >>>> } >>>> } >>>> -------------------------------------------------- >>>> When compiles as in: javac KTest2.java >>>> and executed as in: java KTest2 >>>> can deadlock the hosting JVM as is reproduced by the stack-trace dump, >>>> below: >>>> ------------------------------------------------- >>>> Found one Java-level deadlock: >>>> ============================= >>>> "Thread-0": >>>> waiting to lock monitor 0x0921d720 (object 0xa5621b80, a >>>> sun.security.krb5.internal.rcache.CacheTable), >>>> which is held by "main" >>>> "main": >>>> waiting to lock monitor 0x0921caa0 (object 0xa5622fb8, a >>>> sun.security.krb5.internal.rcache.ReplayCache), >>>> which is held by "Thread-0" >>>> >>>> Java stack information for the threads listed above: >>>> =================================================== >>>> "Thread-0": >>>> at java.util.Hashtable.remove(Hashtable.java:435) >>>> - waiting to lock<0xa5621b80> (a >>>> sun.security.krb5.internal.rcache.CacheTable) >>>> at >>>> sun.security.krb5.internal.rcache.ReplayCache.put(ReplayCache.java:123) >>>> - locked<0xa5622fb8> (a >>>> sun.security.krb5.internal.rcache.ReplayCache) >>>> at KTest2$1.run(KTest2.java:13) >>>> "main": >>>> at >>>> sun.security.krb5.internal.rcache.ReplayCache.put(ReplayCache.java:62) >>>> - waiting to lock<0xa5622fb8> (a >>>> sun.security.krb5.internal.rcache.ReplayCache) >>>> at >>>> sun.security.krb5.internal.rcache.CacheTable.put(CacheTable.java:59) >>>> - locked<0xa5621b80> (a >>>> sun.security.krb5.internal.rcache.CacheTable) >>>> at KTest2.main(KTest2.java:16) >>>> >>>> Found 1 deadlock. >>>> ... >>>> >>> > > From weijun.wang at oracle.com Fri Jan 13 01:51:25 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 13 Jan 2012 01:51:25 +0000 Subject: hg: jdk8/tl/jdk: 7090565: Move test/closed/javax/security/auth/x500/X500Principal/Parse.java to open tests Message-ID: <20120113015144.632D54794D@hg.openjdk.java.net> Changeset: 38bf1e9b6979 Author: weijun Date: 2012-01-13 09:50 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/38bf1e9b6979 7090565: Move test/closed/javax/security/auth/x500/X500Principal/Parse.java to open tests Reviewed-by: mullan + test/javax/security/auth/x500/X500Principal/NameFormat.java From valerie.peng at oracle.com Fri Jan 13 01:58:18 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 12 Jan 2012 17:58:18 -0800 Subject: code review request: 7118809: rcache deadlock In-Reply-To: <4F0F8D0A.2080501@oracle.com> References: <7296394.1325559670063.JavaMail.sbladm@swsblss4-new> <4F0BCF7C.4060400@oracle.com> <4F0E1858.8050106@oracle.com> <4F0E79A6.9060408@oracle.com> <4F0F6AA2.1030801@oracle.com> <4F0F8D0A.2080501@oracle.com> Message-ID: <4F0F8FBA.7@oracle.com> Ok. Thanks, Valerie On 01/12/12 17:46, Weijun Wang wrote: > How about this? We remove the empty ReplayCache in JDK 8 but keep it > in 7u4 (I want to backport it). I just feel there is a hidden monster > somewhere. > > Thanks > Max > > On 01/13/2012 07:20 AM, Valerie (Yu-Ching) Peng wrote: >> >> Secret use? >> As far as I can see, the CacheTable.put(...) method handles the case >> where an ReplayCache object isn't found and I can't think of any secret >> use for this. >> It looks to me that cleaning this up is only an internal impl of >> CacheTable class and should not affect its behavior. >> Removing an empty Cache seems more correct than leaving it there. >> Thanks, >> Valerie >> >> On 01/11/12 22:11, Weijun Wang wrote: >>>> In addition, I think the CacheTable.put(...) method should check if >>>> the >>>> ReplayCache object is empty and if yes, do the removal itself. >>>> So, the cleanup of empty ReplayCache object is still done, except it's >>>> now in CacheTable class instead of ReplayCache class which leads to >>>> the >>>> deadlock. >>> >>> That was my original plan. But I have no idea why in CacheTable >>> there is >>> >>> // re-insert the entry, since rc.put could have removed the entry >>> >>> Does it really have a secret use? >>> >>>> >>>> Lastly, not really relevant to your changes here, but the code in both >>>> classes doesn't seem too efficient and some even looks not quite >>>> correct. >>>> For example, the impl of ReplayCache.put(...) method first goes >>>> through >>>> the LinkList and insert authenticator timestamp in descending order >>>> and >>>> then going through it again removing the expired timestamps. >>>> Wouldn't it >>>> be better to revert the order or doing both together, i.e. check for >>>> expiration and find the indexing while going through the list once? >>> >>> Maybe. >>> >>> Thanks >>> Max >>> >>>> >>>> Thanks, >>>> Valerie >>>> >>>> On 01/09/12 21:41, Weijun Wang wrote: >>>>> Hi Valerie >>>>> >>>>> Please review my fix: >>>>> >>>>> http://cr.openjdk.java.net/~weijun/7118809/webrev.00/ >>>>> >>>>> Basically, CacheTable.put() operates on ReplayCache inside it, and >>>>> ReplayCache.put() operates on CacheTable containing it, and both >>>>> methods are synchronized and using thread-safe Hashtable. >>>>> >>>>> My solution is to move the "table.remove(principal)" line in >>>>> ReplayCache.put() outside the method. I search thru JDK and >>>>> CacheTable.put() is the only place the method is called: >>>>> >>>>> public synchronized void put(String principal, AuthTime time, long >>>>> currTime) { >>>>> ReplayCache rc = super.get(principal); >>>>> if (rc == null) { >>>>> if (DEBUG) { >>>>> System.out.println("replay cache for " + principal + " >>>>> is null."); >>>>> } >>>>> rc = new ReplayCache(principal, this); >>>>> rc.put(time, currTime); >>>>> super.put(principal, rc); >>>>> } >>>>> else { >>>>> rc.put(time, currTime); >>>>> // re-insert the entry, since rc.put could have removed >>>>> the entry >>>>> super.put(principal, rc); >>>>> if (DEBUG) { >>>>> System.out.println("replay cache found."); >>>>> } >>>>> } >>>>> } >>>>> >>>>> Curiously, you can see after each call, the ReplayCache object is >>>>> added back into the CacheTable. Therefore, the remove action is >>>>> useless. >>>>> >>>>> Maybe the most correct way is to remove a ReplayCache from a >>>>> CacheTable if it's empty, but that re-insert line was added in a >>>>> security fix some years ago which I cannot decipher. >>>>> >>>>> So my fix simply removes the "remove" call in ReplayCache. >>>>> >>>>> No regression test, hard to reproduce failure. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> -------- Original Message -------- >>>>> *Change Request ID*: 7118809 >>>>> *Synopsis*: rcache deadlock >>>>> >>>>> === *Description* >>>>> ============================================================ >>>>> A DESCRIPTION OF THE PROBLEM : >>>>> The program as below: >>>>> -------------------------------------------------- >>>>> import sun.security.krb5.internal.rcache.*; >>>>> import sun.security.krb5.internal.*; >>>>> import java.util.*; >>>>> >>>>> public class KTest2 { >>>>> public static void main(String [] a) throws Exception{ >>>>> final CacheTable ct = new CacheTable(); >>>>> final long time = System.currentTimeMillis(); >>>>> ct.put("TheOnlyOne", new AuthTime( time - >>>>> Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * 1000L, 0), time); >>>>> final ReplayCache rc = (ReplayCache) ct.get("TheOnlyOne"); >>>>> new Thread() { >>>>> public void run() { >>>>> rc.put(new AuthTime( time - Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * >>>>> 1000L, 0), time + 300*1000); >>>>> } >>>>> }.start(); >>>>> ct.put("TheOnlyOne", new AuthTime( time - >>>>> Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * 1000L, 0), time); >>>>> } >>>>> } >>>>> -------------------------------------------------- >>>>> When compiles as in: javac KTest2.java >>>>> and executed as in: java KTest2 >>>>> can deadlock the hosting JVM as is reproduced by the stack-trace >>>>> dump, >>>>> below: >>>>> ------------------------------------------------- >>>>> Found one Java-level deadlock: >>>>> ============================= >>>>> "Thread-0": >>>>> waiting to lock monitor 0x0921d720 (object 0xa5621b80, a >>>>> sun.security.krb5.internal.rcache.CacheTable), >>>>> which is held by "main" >>>>> "main": >>>>> waiting to lock monitor 0x0921caa0 (object 0xa5622fb8, a >>>>> sun.security.krb5.internal.rcache.ReplayCache), >>>>> which is held by "Thread-0" >>>>> >>>>> Java stack information for the threads listed above: >>>>> =================================================== >>>>> "Thread-0": >>>>> at java.util.Hashtable.remove(Hashtable.java:435) >>>>> - waiting to lock<0xa5621b80> (a >>>>> sun.security.krb5.internal.rcache.CacheTable) >>>>> at >>>>> sun.security.krb5.internal.rcache.ReplayCache.put(ReplayCache.java:123) >>>>> >>>>> - locked<0xa5622fb8> (a >>>>> sun.security.krb5.internal.rcache.ReplayCache) >>>>> at KTest2$1.run(KTest2.java:13) >>>>> "main": >>>>> at >>>>> sun.security.krb5.internal.rcache.ReplayCache.put(ReplayCache.java:62) >>>>> >>>>> - waiting to lock<0xa5622fb8> (a >>>>> sun.security.krb5.internal.rcache.ReplayCache) >>>>> at >>>>> sun.security.krb5.internal.rcache.CacheTable.put(CacheTable.java:59) >>>>> - locked<0xa5621b80> (a >>>>> sun.security.krb5.internal.rcache.CacheTable) >>>>> at KTest2.main(KTest2.java:16) >>>>> >>>>> Found 1 deadlock. >>>>> ... >>>>> >>>> >> >> From valerie.peng at oracle.com Fri Jan 13 02:56:39 2012 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Fri, 13 Jan 2012 02:56:39 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120113025658.EB51B4794F@hg.openjdk.java.net> Changeset: ef3b6736c074 Author: valeriep Date: 2012-01-12 16:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef3b6736c074 7088989: Improve the performance for T4 by utilizing the newly provided crypto APIs Summary: Added the OracleUcrypto provider for utilizing the Solaris ucrypto API. Reviewed-by: weijun ! make/com/oracle/Makefile + make/com/oracle/net/Makefile + make/com/oracle/nio/Makefile + make/com/oracle/security/ucrypto/FILES_c.gmk + make/com/oracle/security/ucrypto/Makefile + make/com/oracle/security/ucrypto/mapfile-vers + make/com/oracle/util/Makefile ! src/share/lib/security/java.security-solaris ! test/Makefile + test/com/oracle/security/ucrypto/TestAES.java + test/com/oracle/security/ucrypto/TestDigest.java + test/com/oracle/security/ucrypto/TestRSA.java + test/com/oracle/security/ucrypto/UcryptoTest.java ! test/java/security/Provider/DefaultPKCS11.java Changeset: a7ad2fcd7291 Author: valeriep Date: 2012-01-12 18:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7ad2fcd7291 Merge From weijun.wang at oracle.com Fri Jan 13 04:57:40 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 13 Jan 2012 12:57:40 +0800 Subject: code review request: 7118809: rcache deadlock In-Reply-To: <4F0F8FBA.7@oracle.com> References: <7296394.1325559670063.JavaMail.sbladm@swsblss4-new> <4F0BCF7C.4060400@oracle.com> <4F0E1858.8050106@oracle.com> <4F0E79A6.9060408@oracle.com> <4F0F6AA2.1030801@oracle.com> <4F0F8D0A.2080501@oracle.com> <4F0F8FBA.7@oracle.com> Message-ID: <4F0FB9C4.2030205@oracle.com> Hi Valerie Here are the updated webrevs: for 8: http://cr.openjdk.java.net/~weijun/7118809/webrev.01/ for 7u4: http://cr.openjdk.java.net/~weijun/7118809/7u4/webrev.00/ I've added a function test. If CacheTable does not add the ReplayCache, the test would fail. No real regression test for this particular bug because of noreg-hard. Thanks Max On 01/13/2012 09:58 AM, Valerie (Yu-Ching) Peng wrote: > > Ok. > Thanks, > Valerie > > On 01/12/12 17:46, Weijun Wang wrote: >> How about this? We remove the empty ReplayCache in JDK 8 but keep it >> in 7u4 (I want to backport it). I just feel there is a hidden monster >> somewhere. >> >> Thanks >> Max >> >> On 01/13/2012 07:20 AM, Valerie (Yu-Ching) Peng wrote: >>> >>> Secret use? >>> As far as I can see, the CacheTable.put(...) method handles the case >>> where an ReplayCache object isn't found and I can't think of any secret >>> use for this. >>> It looks to me that cleaning this up is only an internal impl of >>> CacheTable class and should not affect its behavior. >>> Removing an empty Cache seems more correct than leaving it there. >>> Thanks, >>> Valerie >>> >>> On 01/11/12 22:11, Weijun Wang wrote: >>>>> In addition, I think the CacheTable.put(...) method should check if >>>>> the >>>>> ReplayCache object is empty and if yes, do the removal itself. >>>>> So, the cleanup of empty ReplayCache object is still done, except it's >>>>> now in CacheTable class instead of ReplayCache class which leads to >>>>> the >>>>> deadlock. >>>> >>>> That was my original plan. But I have no idea why in CacheTable >>>> there is >>>> >>>> // re-insert the entry, since rc.put could have removed the entry >>>> >>>> Does it really have a secret use? >>>> >>>>> >>>>> Lastly, not really relevant to your changes here, but the code in both >>>>> classes doesn't seem too efficient and some even looks not quite >>>>> correct. >>>>> For example, the impl of ReplayCache.put(...) method first goes >>>>> through >>>>> the LinkList and insert authenticator timestamp in descending order >>>>> and >>>>> then going through it again removing the expired timestamps. >>>>> Wouldn't it >>>>> be better to revert the order or doing both together, i.e. check for >>>>> expiration and find the indexing while going through the list once? >>>> >>>> Maybe. >>>> >>>> Thanks >>>> Max >>>> >>>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 01/09/12 21:41, Weijun Wang wrote: >>>>>> Hi Valerie >>>>>> >>>>>> Please review my fix: >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/7118809/webrev.00/ >>>>>> >>>>>> Basically, CacheTable.put() operates on ReplayCache inside it, and >>>>>> ReplayCache.put() operates on CacheTable containing it, and both >>>>>> methods are synchronized and using thread-safe Hashtable. >>>>>> >>>>>> My solution is to move the "table.remove(principal)" line in >>>>>> ReplayCache.put() outside the method. I search thru JDK and >>>>>> CacheTable.put() is the only place the method is called: >>>>>> >>>>>> public synchronized void put(String principal, AuthTime time, long >>>>>> currTime) { >>>>>> ReplayCache rc = super.get(principal); >>>>>> if (rc == null) { >>>>>> if (DEBUG) { >>>>>> System.out.println("replay cache for " + principal + " >>>>>> is null."); >>>>>> } >>>>>> rc = new ReplayCache(principal, this); >>>>>> rc.put(time, currTime); >>>>>> super.put(principal, rc); >>>>>> } >>>>>> else { >>>>>> rc.put(time, currTime); >>>>>> // re-insert the entry, since rc.put could have removed >>>>>> the entry >>>>>> super.put(principal, rc); >>>>>> if (DEBUG) { >>>>>> System.out.println("replay cache found."); >>>>>> } >>>>>> } >>>>>> } >>>>>> >>>>>> Curiously, you can see after each call, the ReplayCache object is >>>>>> added back into the CacheTable. Therefore, the remove action is >>>>>> useless. >>>>>> >>>>>> Maybe the most correct way is to remove a ReplayCache from a >>>>>> CacheTable if it's empty, but that re-insert line was added in a >>>>>> security fix some years ago which I cannot decipher. >>>>>> >>>>>> So my fix simply removes the "remove" call in ReplayCache. >>>>>> >>>>>> No regression test, hard to reproduce failure. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> -------- Original Message -------- >>>>>> *Change Request ID*: 7118809 >>>>>> *Synopsis*: rcache deadlock >>>>>> >>>>>> === *Description* >>>>>> ============================================================ >>>>>> A DESCRIPTION OF THE PROBLEM : >>>>>> The program as below: >>>>>> -------------------------------------------------- >>>>>> import sun.security.krb5.internal.rcache.*; >>>>>> import sun.security.krb5.internal.*; >>>>>> import java.util.*; >>>>>> >>>>>> public class KTest2 { >>>>>> public static void main(String [] a) throws Exception{ >>>>>> final CacheTable ct = new CacheTable(); >>>>>> final long time = System.currentTimeMillis(); >>>>>> ct.put("TheOnlyOne", new AuthTime( time - >>>>>> Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * 1000L, 0), time); >>>>>> final ReplayCache rc = (ReplayCache) ct.get("TheOnlyOne"); >>>>>> new Thread() { >>>>>> public void run() { >>>>>> rc.put(new AuthTime( time - Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * >>>>>> 1000L, 0), time + 300*1000); >>>>>> } >>>>>> }.start(); >>>>>> ct.put("TheOnlyOne", new AuthTime( time - >>>>>> Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * 1000L, 0), time); >>>>>> } >>>>>> } >>>>>> -------------------------------------------------- >>>>>> When compiles as in: javac KTest2.java >>>>>> and executed as in: java KTest2 >>>>>> can deadlock the hosting JVM as is reproduced by the stack-trace >>>>>> dump, >>>>>> below: >>>>>> ------------------------------------------------- >>>>>> Found one Java-level deadlock: >>>>>> ============================= >>>>>> "Thread-0": >>>>>> waiting to lock monitor 0x0921d720 (object 0xa5621b80, a >>>>>> sun.security.krb5.internal.rcache.CacheTable), >>>>>> which is held by "main" >>>>>> "main": >>>>>> waiting to lock monitor 0x0921caa0 (object 0xa5622fb8, a >>>>>> sun.security.krb5.internal.rcache.ReplayCache), >>>>>> which is held by "Thread-0" >>>>>> >>>>>> Java stack information for the threads listed above: >>>>>> =================================================== >>>>>> "Thread-0": >>>>>> at java.util.Hashtable.remove(Hashtable.java:435) >>>>>> - waiting to lock<0xa5621b80> (a >>>>>> sun.security.krb5.internal.rcache.CacheTable) >>>>>> at >>>>>> sun.security.krb5.internal.rcache.ReplayCache.put(ReplayCache.java:123) >>>>>> >>>>>> - locked<0xa5622fb8> (a >>>>>> sun.security.krb5.internal.rcache.ReplayCache) >>>>>> at KTest2$1.run(KTest2.java:13) >>>>>> "main": >>>>>> at >>>>>> sun.security.krb5.internal.rcache.ReplayCache.put(ReplayCache.java:62) >>>>>> >>>>>> - waiting to lock<0xa5622fb8> (a >>>>>> sun.security.krb5.internal.rcache.ReplayCache) >>>>>> at >>>>>> sun.security.krb5.internal.rcache.CacheTable.put(CacheTable.java:59) >>>>>> - locked<0xa5621b80> (a >>>>>> sun.security.krb5.internal.rcache.CacheTable) >>>>>> at KTest2.main(KTest2.java:16) >>>>>> >>>>>> Found 1 deadlock. >>>>>> ... >>>>>> >>>>> >>> >>> > From alan.bateman at oracle.com Fri Jan 13 13:32:13 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 13 Jan 2012 13:32:13 +0000 Subject: hg: jdk8/tl/jdk: 7129029: (fs) Unix file system provider should be buildable on platforms that don't support O_NOFOLLOW Message-ID: <20120113133235.A9F634795E@hg.openjdk.java.net> Changeset: 7e593aa6ad41 Author: littlee Date: 2012-01-13 13:20 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7e593aa6ad41 7129029: (fs) Unix file system provider should be buildable on platforms that don't support O_NOFOLLOW Reviewed-by: alanb ! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/native/sun/nio/fs/genUnixConstants.c From sean.mullan at oracle.com Fri Jan 13 17:30:41 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 13 Jan 2012 12:30:41 -0500 Subject: 7u Code review request for 7033170, 7092821, 7092825 In-Reply-To: <4F0F677B.4090406@oracle.com> References: <4EF1157C.7030506@oracle.com> <4EF23034.8030208@oracle.com> <4EF248F6.3080000@oracle.com> <4F0E31B9.8040609@oracle.com> <4F0F677B.4090406@oracle.com> Message-ID: <4F106A41.3090103@oracle.com> On 1/12/12 6:06 PM, Valerie (Yu-Ching) Peng wrote: > Dave, > Thanks for the comments. > Let me think about it some more and see how to better address this kind > of racing issue. > > If you have concerns on fixes for 7033170 and 7092825, please let me know. > > Sean, > Can you please ignore the review request for 7092821 for now. I'll send > out an updated version later. > If you can still review the remaining two, that'd be great. The fixes for 7033170 and 7092825. I didn't see any difference in the 8 and 7u webrevs for 7092825 though - did I miss something? --Sean > > Thanks, > Valerie > > On 01/11/12 21:48, David Schlosnagle wrote: >> On Wed, Jan 11, 2012 at 8:04 PM, Valerie (Yu-Ching) Peng >> wrote: >>> 7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck. >>> jdk7u Webrev: http://cr.openjdk.java.net/~valeriep/7092821_7u/ >>> jdk8 Webrev: http://cr.openjdk.java.net/~valeriep/7092821/ >> Valerie, >> >> You might already be aware of this, but there is a data race on lines >> 685 - 686 of the Provider's getService(String, String) method. If >> there are concurrent callers to getService while lookupCache == null, >> the lookupCache may be overwritten by a new ConcurrentHashMap after >> another thread has just instantiated and populated an entry in the >> cache leading to thrashing on lookupCache. It might be worthwhile to >> either use a double checked lock to avoid the race at the expense of >> an additional lock and volatile read in the case lookupCache == null >> or add a comment indicating that this is an accepted data race. >> >> There is also now the possibility that if one thread is executing >> getService while another thread invokes one of the methods that sets >> lookupCache = null, there could then be a NullPointerException on line >> 703 as the volatile read would now see a null and fail. You could >> prevent that by either moving the putIfAbsent under the lock (not >> ideal for performance if you're already seeing contention), or just >> maintain a local reference to the cache map and use it throughout the >> getService method. This would mean that if the lookupCache reference >> was concurrently mutated, the putIfAbsent would basically be a write >> to the local map reference which is now garbage, but shouldn't really >> hurt anything. >> >> I'd propose something along the lines of the following to address this: >> >> public Service getService(String type, String algorithm) { >> ServiceKey key = new ServiceKey(type, algorithm); >> ConcurrentMap localLookupCache = getLookupCache(); >> Service result = localLookupCache.get(key); >> if (result != null) { >> return (result == NULL_MARK? null : result); >> } >> synchronized (this) { >> checkInitialized(); >> if (serviceMap != null) { >> result = serviceMap.get(key); >> } >> if (result == null) { >> ensureLegacyParsed(); >> result = (legacyMap != null) ? legacyMap.get(key) : null; >> } >> } >> // under concurrent mutation of lookupCache, this will write >> to map that is no >> // longer the active cache >> localLookupCache.putIfAbsent(key, (result == null? NULL_MARK : result)); >> return result; >> } >> >> private ConcurrentMap getLookupCache() { >> if (lookupCache == null) { >> synchronized (this) { >> // must fall back on double checked lock >> if (lookupCache == null) { >> lookupCache = new ConcurrentHashMap<>(); >> } >> } >> } >> return lookupCache; >> } >> >> >> - Dave >> >> >> For reference, here were the original changes: >> 429 // Cache for service lookups. Discard whenever services are changed. >> 430 private transient volatile ConcurrentMap >> lookupCache; >> ...snip... >> 682 public Service getService(String type, String algorithm) { >> 683 ServiceKey key = new ServiceKey(type, algorithm); >> 684 Service result = null; >> 685 if (lookupCache == null) { >> 686 lookupCache = new ConcurrentHashMap<>(); >> 687 } else { >> 688 result = lookupCache.get(key); >> 689 if (result != null) { >> 690 return (result == NULL_MARK? null : result); >> 691 } >> 692 } >> 693 synchronized (this) { >> 694 checkInitialized(); >> 695 if (serviceMap != null) { >> 696 result = serviceMap.get(key); >> 697 } >> 698 if (result == null) { >> 699 ensureLegacyParsed(); >> 700 result = (legacyMap != null) ? legacyMap.get(key) : null; >> 701 } >> 702 } >> 703 lookupCache.putIfAbsent(key, (result == null? NULL_MARK : result)); >> 704 return result; >> 705 } > From sean.mullan at oracle.com Fri Jan 13 17:33:07 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 13 Jan 2012 12:33:07 -0500 Subject: 7u Code review request for 7033170, 7092821, 7092825 In-Reply-To: <4F106A41.3090103@oracle.com> References: <4EF1157C.7030506@oracle.com> <4EF23034.8030208@oracle.com> <4EF248F6.3080000@oracle.com> <4F0E31B9.8040609@oracle.com> <4F0F677B.4090406@oracle.com> <4F106A41.3090103@oracle.com> Message-ID: <4F106AD3.2010100@oracle.com> On 1/13/12 12:30 PM, Sean Mullan wrote: > On 1/12/12 6:06 PM, Valerie (Yu-Ching) Peng wrote: >> Dave, >> Thanks for the comments. >> Let me think about it some more and see how to better address this kind >> of racing issue. >> >> If you have concerns on fixes for 7033170 and 7092825, please let me know. >> >> Sean, >> Can you please ignore the review request for 7092821 for now. I'll send >> out an updated version later. >> If you can still review the remaining two, that'd be great. > > The fixes for 7033170 and 7092825. I didn't see any difference in the 8 and 7u > webrevs for 7092825 though - did I miss something? I meant to write: The fixes for 7033170 and 7092825 look fine. I didn't see any difference in the 8 and 7u webrevs for 7092825 though - did I miss something? --Sean > > --Sean > >> >> Thanks, >> Valerie >> >> On 01/11/12 21:48, David Schlosnagle wrote: >>> On Wed, Jan 11, 2012 at 8:04 PM, Valerie (Yu-Ching) Peng >>> wrote: >>>> 7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck. >>>> jdk7u Webrev: http://cr.openjdk.java.net/~valeriep/7092821_7u/ >>>> jdk8 Webrev: http://cr.openjdk.java.net/~valeriep/7092821/ >>> Valerie, >>> >>> You might already be aware of this, but there is a data race on lines >>> 685 - 686 of the Provider's getService(String, String) method. If >>> there are concurrent callers to getService while lookupCache == null, >>> the lookupCache may be overwritten by a new ConcurrentHashMap after >>> another thread has just instantiated and populated an entry in the >>> cache leading to thrashing on lookupCache. It might be worthwhile to >>> either use a double checked lock to avoid the race at the expense of >>> an additional lock and volatile read in the case lookupCache == null >>> or add a comment indicating that this is an accepted data race. >>> >>> There is also now the possibility that if one thread is executing >>> getService while another thread invokes one of the methods that sets >>> lookupCache = null, there could then be a NullPointerException on line >>> 703 as the volatile read would now see a null and fail. You could >>> prevent that by either moving the putIfAbsent under the lock (not >>> ideal for performance if you're already seeing contention), or just >>> maintain a local reference to the cache map and use it throughout the >>> getService method. This would mean that if the lookupCache reference >>> was concurrently mutated, the putIfAbsent would basically be a write >>> to the local map reference which is now garbage, but shouldn't really >>> hurt anything. >>> >>> I'd propose something along the lines of the following to address this: >>> >>> public Service getService(String type, String algorithm) { >>> ServiceKey key = new ServiceKey(type, algorithm); >>> ConcurrentMap localLookupCache = getLookupCache(); >>> Service result = localLookupCache.get(key); >>> if (result != null) { >>> return (result == NULL_MARK? null : result); >>> } >>> synchronized (this) { >>> checkInitialized(); >>> if (serviceMap != null) { >>> result = serviceMap.get(key); >>> } >>> if (result == null) { >>> ensureLegacyParsed(); >>> result = (legacyMap != null) ? legacyMap.get(key) : null; >>> } >>> } >>> // under concurrent mutation of lookupCache, this will write >>> to map that is no >>> // longer the active cache >>> localLookupCache.putIfAbsent(key, (result == null? NULL_MARK : result)); >>> return result; >>> } >>> >>> private ConcurrentMap getLookupCache() { >>> if (lookupCache == null) { >>> synchronized (this) { >>> // must fall back on double checked lock >>> if (lookupCache == null) { >>> lookupCache = new ConcurrentHashMap<>(); >>> } >>> } >>> } >>> return lookupCache; >>> } >>> >>> >>> - Dave >>> >>> >>> For reference, here were the original changes: >>> 429 // Cache for service lookups. Discard whenever services are changed. >>> 430 private transient volatile ConcurrentMap >>> lookupCache; >>> ...snip... >>> 682 public Service getService(String type, String algorithm) { >>> 683 ServiceKey key = new ServiceKey(type, algorithm); >>> 684 Service result = null; >>> 685 if (lookupCache == null) { >>> 686 lookupCache = new ConcurrentHashMap<>(); >>> 687 } else { >>> 688 result = lookupCache.get(key); >>> 689 if (result != null) { >>> 690 return (result == NULL_MARK? null : result); >>> 691 } >>> 692 } >>> 693 synchronized (this) { >>> 694 checkInitialized(); >>> 695 if (serviceMap != null) { >>> 696 result = serviceMap.get(key); >>> 697 } >>> 698 if (result == null) { >>> 699 ensureLegacyParsed(); >>> 700 result = (legacyMap != null) ? legacyMap.get(key) : null; >>> 701 } >>> 702 } >>> 703 lookupCache.putIfAbsent(key, (result == null? NULL_MARK : result)); >>> 704 return result; >>> 705 } >> From valerie.peng at oracle.com Fri Jan 13 23:16:53 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Fri, 13 Jan 2012 15:16:53 -0800 Subject: 7u Code review request for 7033170, 7092821, 7092825 In-Reply-To: <4F106AD3.2010100@oracle.com> References: <4EF1157C.7030506@oracle.com> <4EF23034.8030208@oracle.com> <4EF248F6.3080000@oracle.com> <4F0E31B9.8040609@oracle.com> <4F0F677B.4090406@oracle.com> <4F106A41.3090103@oracle.com> <4F106AD3.2010100@oracle.com> Message-ID: <4F10BB65.8080007@oracle.com> I applied the same changes for 7092825 to both jdk8 and 7u. The webrevs are generated against different workspaces. What other differences do you expect? Valerie On 01/13/12 09:33, Sean Mullan wrote: > On 1/13/12 12:30 PM, Sean Mullan wrote: >> On 1/12/12 6:06 PM, Valerie (Yu-Ching) Peng wrote: >>> Dave, >>> Thanks for the comments. >>> Let me think about it some more and see how to better address this kind >>> of racing issue. >>> >>> If you have concerns on fixes for 7033170 and 7092825, please let me know. >>> >>> Sean, >>> Can you please ignore the review request for 7092821 for now. I'll send >>> out an updated version later. >>> If you can still review the remaining two, that'd be great. >> The fixes for 7033170 and 7092825. I didn't see any difference in the 8 and 7u >> webrevs for 7092825 though - did I miss something? > I meant to write: > > The fixes for 7033170 and 7092825 look fine. I didn't see any difference in the > 8 and 7u webrevs for 7092825 though - did I miss something? > > --Sean >> --Sean >> >>> Thanks, >>> Valerie >>> >>> On 01/11/12 21:48, David Schlosnagle wrote: >>>> On Wed, Jan 11, 2012 at 8:04 PM, Valerie (Yu-Ching) Peng >>>> wrote: >>>>> 7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck. >>>>> jdk7u Webrev: http://cr.openjdk.java.net/~valeriep/7092821_7u/ >>>>> jdk8 Webrev: http://cr.openjdk.java.net/~valeriep/7092821/ >>>> Valerie, >>>> >>>> You might already be aware of this, but there is a data race on lines >>>> 685 - 686 of the Provider's getService(String, String) method. If >>>> there are concurrent callers to getService while lookupCache == null, >>>> the lookupCache may be overwritten by a new ConcurrentHashMap after >>>> another thread has just instantiated and populated an entry in the >>>> cache leading to thrashing on lookupCache. It might be worthwhile to >>>> either use a double checked lock to avoid the race at the expense of >>>> an additional lock and volatile read in the case lookupCache == null >>>> or add a comment indicating that this is an accepted data race. >>>> >>>> There is also now the possibility that if one thread is executing >>>> getService while another thread invokes one of the methods that sets >>>> lookupCache = null, there could then be a NullPointerException on line >>>> 703 as the volatile read would now see a null and fail. You could >>>> prevent that by either moving the putIfAbsent under the lock (not >>>> ideal for performance if you're already seeing contention), or just >>>> maintain a local reference to the cache map and use it throughout the >>>> getService method. This would mean that if the lookupCache reference >>>> was concurrently mutated, the putIfAbsent would basically be a write >>>> to the local map reference which is now garbage, but shouldn't really >>>> hurt anything. >>>> >>>> I'd propose something along the lines of the following to address this: >>>> >>>> public Service getService(String type, String algorithm) { >>>> ServiceKey key = new ServiceKey(type, algorithm); >>>> ConcurrentMap localLookupCache = getLookupCache(); >>>> Service result = localLookupCache.get(key); >>>> if (result != null) { >>>> return (result == NULL_MARK? null : result); >>>> } >>>> synchronized (this) { >>>> checkInitialized(); >>>> if (serviceMap != null) { >>>> result = serviceMap.get(key); >>>> } >>>> if (result == null) { >>>> ensureLegacyParsed(); >>>> result = (legacyMap != null) ? legacyMap.get(key) : null; >>>> } >>>> } >>>> // under concurrent mutation of lookupCache, this will write >>>> to map that is no >>>> // longer the active cache >>>> localLookupCache.putIfAbsent(key, (result == null? NULL_MARK : result)); >>>> return result; >>>> } >>>> >>>> private ConcurrentMap getLookupCache() { >>>> if (lookupCache == null) { >>>> synchronized (this) { >>>> // must fall back on double checked lock >>>> if (lookupCache == null) { >>>> lookupCache = new ConcurrentHashMap<>(); >>>> } >>>> } >>>> } >>>> return lookupCache; >>>> } >>>> >>>> >>>> - Dave >>>> >>>> >>>> For reference, here were the original changes: >>>> 429 // Cache for service lookups. Discard whenever services are changed. >>>> 430 private transient volatile ConcurrentMap >>>> lookupCache; >>>> ...snip... >>>> 682 public Service getService(String type, String algorithm) { >>>> 683 ServiceKey key = new ServiceKey(type, algorithm); >>>> 684 Service result = null; >>>> 685 if (lookupCache == null) { >>>> 686 lookupCache = new ConcurrentHashMap<>(); >>>> 687 } else { >>>> 688 result = lookupCache.get(key); >>>> 689 if (result != null) { >>>> 690 return (result == NULL_MARK? null : result); >>>> 691 } >>>> 692 } >>>> 693 synchronized (this) { >>>> 694 checkInitialized(); >>>> 695 if (serviceMap != null) { >>>> 696 result = serviceMap.get(key); >>>> 697 } >>>> 698 if (result == null) { >>>> 699 ensureLegacyParsed(); >>>> 700 result = (legacyMap != null) ? legacyMap.get(key) : null; >>>> 701 } >>>> 702 } >>>> 703 lookupCache.putIfAbsent(key, (result == null? NULL_MARK : result)); >>>> 704 return result; >>>> 705 } From valerie.peng at oracle.com Fri Jan 13 23:29:19 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Fri, 13 Jan 2012 15:29:19 -0800 Subject: code review request: 7118809: rcache deadlock In-Reply-To: <4F0FB9C4.2030205@oracle.com> References: <7296394.1325559670063.JavaMail.sbladm@swsblss4-new> <4F0BCF7C.4060400@oracle.com> <4F0E1858.8050106@oracle.com> <4F0E79A6.9060408@oracle.com> <4F0F6AA2.1030801@oracle.com> <4F0F8D0A.2080501@oracle.com> <4F0F8FBA.7@oracle.com> <4F0FB9C4.2030205@oracle.com> Message-ID: <4F10BE4F.8030006@oracle.com> Ok, I have no other comments. Thanks, Valerie On 01/12/12 20:57, Weijun Wang wrote: > Hi Valerie > > Here are the updated webrevs: > > for 8: http://cr.openjdk.java.net/~weijun/7118809/webrev.01/ > for 7u4: http://cr.openjdk.java.net/~weijun/7118809/7u4/webrev.00/ > > I've added a function test. If CacheTable does not add the > ReplayCache, the test would fail. No real regression test for this > particular bug because of noreg-hard. > > Thanks > Max > > > On 01/13/2012 09:58 AM, Valerie (Yu-Ching) Peng wrote: >> >> Ok. >> Thanks, >> Valerie >> >> On 01/12/12 17:46, Weijun Wang wrote: >>> How about this? We remove the empty ReplayCache in JDK 8 but keep it >>> in 7u4 (I want to backport it). I just feel there is a hidden monster >>> somewhere. >>> >>> Thanks >>> Max >>> >>> On 01/13/2012 07:20 AM, Valerie (Yu-Ching) Peng wrote: >>>> >>>> Secret use? >>>> As far as I can see, the CacheTable.put(...) method handles the case >>>> where an ReplayCache object isn't found and I can't think of any >>>> secret >>>> use for this. >>>> It looks to me that cleaning this up is only an internal impl of >>>> CacheTable class and should not affect its behavior. >>>> Removing an empty Cache seems more correct than leaving it there. >>>> Thanks, >>>> Valerie >>>> >>>> On 01/11/12 22:11, Weijun Wang wrote: >>>>>> In addition, I think the CacheTable.put(...) method should check if >>>>>> the >>>>>> ReplayCache object is empty and if yes, do the removal itself. >>>>>> So, the cleanup of empty ReplayCache object is still done, except >>>>>> it's >>>>>> now in CacheTable class instead of ReplayCache class which leads to >>>>>> the >>>>>> deadlock. >>>>> >>>>> That was my original plan. But I have no idea why in CacheTable >>>>> there is >>>>> >>>>> // re-insert the entry, since rc.put could have removed the entry >>>>> >>>>> Does it really have a secret use? >>>>> >>>>>> >>>>>> Lastly, not really relevant to your changes here, but the code in >>>>>> both >>>>>> classes doesn't seem too efficient and some even looks not quite >>>>>> correct. >>>>>> For example, the impl of ReplayCache.put(...) method first goes >>>>>> through >>>>>> the LinkList and insert authenticator timestamp in descending order >>>>>> and >>>>>> then going through it again removing the expired timestamps. >>>>>> Wouldn't it >>>>>> be better to revert the order or doing both together, i.e. check for >>>>>> expiration and find the indexing while going through the list once? >>>>> >>>>> Maybe. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> On 01/09/12 21:41, Weijun Wang wrote: >>>>>>> Hi Valerie >>>>>>> >>>>>>> Please review my fix: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~weijun/7118809/webrev.00/ >>>>>>> >>>>>>> Basically, CacheTable.put() operates on ReplayCache inside it, and >>>>>>> ReplayCache.put() operates on CacheTable containing it, and both >>>>>>> methods are synchronized and using thread-safe Hashtable. >>>>>>> >>>>>>> My solution is to move the "table.remove(principal)" line in >>>>>>> ReplayCache.put() outside the method. I search thru JDK and >>>>>>> CacheTable.put() is the only place the method is called: >>>>>>> >>>>>>> public synchronized void put(String principal, AuthTime time, long >>>>>>> currTime) { >>>>>>> ReplayCache rc = super.get(principal); >>>>>>> if (rc == null) { >>>>>>> if (DEBUG) { >>>>>>> System.out.println("replay cache for " + principal + " >>>>>>> is null."); >>>>>>> } >>>>>>> rc = new ReplayCache(principal, this); >>>>>>> rc.put(time, currTime); >>>>>>> super.put(principal, rc); >>>>>>> } >>>>>>> else { >>>>>>> rc.put(time, currTime); >>>>>>> // re-insert the entry, since rc.put could have removed >>>>>>> the entry >>>>>>> super.put(principal, rc); >>>>>>> if (DEBUG) { >>>>>>> System.out.println("replay cache found."); >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> Curiously, you can see after each call, the ReplayCache object is >>>>>>> added back into the CacheTable. Therefore, the remove action is >>>>>>> useless. >>>>>>> >>>>>>> Maybe the most correct way is to remove a ReplayCache from a >>>>>>> CacheTable if it's empty, but that re-insert line was added in a >>>>>>> security fix some years ago which I cannot decipher. >>>>>>> >>>>>>> So my fix simply removes the "remove" call in ReplayCache. >>>>>>> >>>>>>> No regression test, hard to reproduce failure. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> -------- Original Message -------- >>>>>>> *Change Request ID*: 7118809 >>>>>>> *Synopsis*: rcache deadlock >>>>>>> >>>>>>> === *Description* >>>>>>> ============================================================ >>>>>>> A DESCRIPTION OF THE PROBLEM : >>>>>>> The program as below: >>>>>>> -------------------------------------------------- >>>>>>> import sun.security.krb5.internal.rcache.*; >>>>>>> import sun.security.krb5.internal.*; >>>>>>> import java.util.*; >>>>>>> >>>>>>> public class KTest2 { >>>>>>> public static void main(String [] a) throws Exception{ >>>>>>> final CacheTable ct = new CacheTable(); >>>>>>> final long time = System.currentTimeMillis(); >>>>>>> ct.put("TheOnlyOne", new AuthTime( time - >>>>>>> Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * 1000L, 0), time); >>>>>>> final ReplayCache rc = (ReplayCache) ct.get("TheOnlyOne"); >>>>>>> new Thread() { >>>>>>> public void run() { >>>>>>> rc.put(new AuthTime( time - Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * >>>>>>> 1000L, 0), time + 300*1000); >>>>>>> } >>>>>>> }.start(); >>>>>>> ct.put("TheOnlyOne", new AuthTime( time - >>>>>>> Krb5.DEFAULT_ALLOWABLE_CLOCKSKEW * 1000L, 0), time); >>>>>>> } >>>>>>> } >>>>>>> -------------------------------------------------- >>>>>>> When compiles as in: javac KTest2.java >>>>>>> and executed as in: java KTest2 >>>>>>> can deadlock the hosting JVM as is reproduced by the stack-trace >>>>>>> dump, >>>>>>> below: >>>>>>> ------------------------------------------------- >>>>>>> Found one Java-level deadlock: >>>>>>> ============================= >>>>>>> "Thread-0": >>>>>>> waiting to lock monitor 0x0921d720 (object 0xa5621b80, a >>>>>>> sun.security.krb5.internal.rcache.CacheTable), >>>>>>> which is held by "main" >>>>>>> "main": >>>>>>> waiting to lock monitor 0x0921caa0 (object 0xa5622fb8, a >>>>>>> sun.security.krb5.internal.rcache.ReplayCache), >>>>>>> which is held by "Thread-0" >>>>>>> >>>>>>> Java stack information for the threads listed above: >>>>>>> =================================================== >>>>>>> "Thread-0": >>>>>>> at java.util.Hashtable.remove(Hashtable.java:435) >>>>>>> - waiting to lock<0xa5621b80> (a >>>>>>> sun.security.krb5.internal.rcache.CacheTable) >>>>>>> at >>>>>>> sun.security.krb5.internal.rcache.ReplayCache.put(ReplayCache.java:123) >>>>>>> >>>>>>> >>>>>>> - locked<0xa5622fb8> (a >>>>>>> sun.security.krb5.internal.rcache.ReplayCache) >>>>>>> at KTest2$1.run(KTest2.java:13) >>>>>>> "main": >>>>>>> at >>>>>>> sun.security.krb5.internal.rcache.ReplayCache.put(ReplayCache.java:62) >>>>>>> >>>>>>> >>>>>>> - waiting to lock<0xa5622fb8> (a >>>>>>> sun.security.krb5.internal.rcache.ReplayCache) >>>>>>> at >>>>>>> sun.security.krb5.internal.rcache.CacheTable.put(CacheTable.java:59) >>>>>>> >>>>>>> - locked<0xa5621b80> (a >>>>>>> sun.security.krb5.internal.rcache.CacheTable) >>>>>>> at KTest2.main(KTest2.java:16) >>>>>>> >>>>>>> Found 1 deadlock. >>>>>>> ... >>>>>>> >>>>>> >>>> >>>> >> From weijun.wang at oracle.com Mon Jan 16 02:14:45 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 16 Jan 2012 02:14:45 +0000 Subject: hg: jdk8/tl/jdk: 7118809: rcache deadlock Message-ID: <20120116021517.899F94797D@hg.openjdk.java.net> Changeset: e8e08d46cc37 Author: weijun Date: 2012-01-16 10:10 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8e08d46cc37 7118809: rcache deadlock Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java ! src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/ReplayCache.java From alan.bateman at oracle.com Mon Jan 16 16:31:26 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 16 Jan 2012 16:31:26 +0000 Subject: hg: jdk8/tl/jdk: 7130398: ProblemList.txt updates (1/2012) Message-ID: <20120116163149.C44094798C@hg.openjdk.java.net> Changeset: d1b0bda3a3c7 Author: alanb Date: 2012-01-16 16:30 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1b0bda3a3c7 7130398: ProblemList.txt updates (1/2012) Reviewed-by: chegar ! test/ProblemList.txt From chris.hegarty at oracle.com Mon Jan 16 21:28:04 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 16 Jan 2012 21:28:04 +0000 Subject: hg: jdk8/tl/jdk: 7129083: CookieManager does not store cookies if url is read before setting cookie manager Message-ID: <20120116212828.15AF54798E@hg.openjdk.java.net> Changeset: e8a143213c65 Author: chegar Date: 2012-01-16 18:05 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8a143213c65 7129083: CookieManager does not store cookies if url is read before setting cookie manager Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java + test/sun/net/www/http/HttpClient/CookieHttpClientTest.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java From chris.hegarty at oracle.com Tue Jan 17 16:51:18 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 17 Jan 2012 16:51:18 +0000 Subject: hg: jdk8/tl/jdk: 6671616: TEST_BUG: java/io/File/BlockIsDirectory.java fails when /dev/dsk empty (sol) Message-ID: <20120117165139.0ECB64799E@hg.openjdk.java.net> Changeset: 40d699d7f6a1 Author: chegar Date: 2012-01-17 14:10 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40d699d7f6a1 6671616: TEST_BUG: java/io/File/BlockIsDirectory.java fails when /dev/dsk empty (sol) Reviewed-by: alanb ! test/ProblemList.txt - test/java/io/File/BlockIsDirectory.java From jim.holmlund at sun.com Wed Jan 18 01:19:44 2012 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Wed, 18 Jan 2012 01:19:44 +0000 Subject: hg: jdk8/tl/langtools: 7127924: langtools regression tests sometimes fail en-masse on windows Message-ID: <20120118011947.69437479AC@hg.openjdk.java.net> Changeset: 1e2f4f4fb9f7 Author: jjh Date: 2012-01-17 17:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1e2f4f4fb9f7 7127924: langtools regression tests sometimes fail en-masse on windows Reviewed-by: jjg ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java From mandy.chung at oracle.com Wed Jan 18 02:03:55 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 18 Jan 2012 02:03:55 +0000 Subject: hg: jdk8/tl/jdk: 7117570: Warnings in sun.mangement.* and its subpackages Message-ID: <20120118020408.796D4479AE@hg.openjdk.java.net> Changeset: 2f096eb72520 Author: mchung Date: 2012-01-17 15:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2f096eb72520 7117570: Warnings in sun.mangement.* and its subpackages Reviewed-by: mchung, dsamersoff Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/sun/management/Agent.java ! src/share/classes/sun/management/ConnectorAddressLink.java ! src/share/classes/sun/management/Flag.java ! src/share/classes/sun/management/GarbageCollectionNotifInfoCompositeData.java ! src/share/classes/sun/management/GarbageCollectorImpl.java ! src/share/classes/sun/management/GcInfoBuilder.java ! src/share/classes/sun/management/GcInfoCompositeData.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/management/HotspotCompilation.java ! src/share/classes/sun/management/HotspotThread.java ! src/share/classes/sun/management/LazyCompositeData.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/management/MonitorInfoCompositeData.java ! src/share/classes/sun/management/NotificationEmitterSupport.java ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/ThreadInfoCompositeData.java ! src/share/classes/sun/management/counter/perf/PerfInstrumentation.java ! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java ! src/share/classes/sun/management/snmp/AdaptorBootstrap.java ! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemGCTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemManagerTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemMgrPoolRelTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemPoolTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmOSImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRuntimeMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadingMetaImpl.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmClassesVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmJITCompilerTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemManagerState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolCollectThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolType.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCCall.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmRTBootClassPathSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadContentionMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadCpuTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIB.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIBOidTable.java ! src/share/classes/sun/management/snmp/jvmmib/JvmClassLoadingMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmCompilationMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmOSMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRuntimeMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadingMeta.java ! src/share/classes/sun/management/snmp/util/MibLogger.java ! src/share/classes/sun/management/snmp/util/SnmpListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpTableCache.java From lana.steuck at oracle.com Wed Jan 18 20:17:07 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 18 Jan 2012 20:17:07 +0000 Subject: hg: jdk8/tl: 3 new changesets Message-ID: <20120118201708.06880479C2@hg.openjdk.java.net> Changeset: 5a5eaf6374bc Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/5a5eaf6374bc Added tag jdk8-b19 for changeset 237bc29afbfc ! .hgtags Changeset: cc771d92284f Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cc771d92284f Added tag jdk8-b20 for changeset 5a5eaf6374bc ! .hgtags Changeset: 7ad075c80995 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7ad075c80995 Added tag jdk8-b21 for changeset cc771d92284f ! .hgtags From lana.steuck at oracle.com Wed Jan 18 20:17:06 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 18 Jan 2012 20:17:06 +0000 Subject: hg: jdk8/tl/corba: 3 new changesets Message-ID: <20120118201711.0B5BA479C3@hg.openjdk.java.net> Changeset: 51d8b6cb18c0 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/51d8b6cb18c0 Added tag jdk8-b19 for changeset e1366c5d84ef ! .hgtags Changeset: f157fc2a71a3 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/f157fc2a71a3 Added tag jdk8-b20 for changeset 51d8b6cb18c0 ! .hgtags Changeset: a11d0062c445 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/a11d0062c445 Added tag jdk8-b21 for changeset f157fc2a71a3 ! .hgtags From lana.steuck at oracle.com Wed Jan 18 20:17:12 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 18 Jan 2012 20:17:12 +0000 Subject: hg: jdk8/tl/jaxws: 5 new changesets Message-ID: <20120118201712.59F05479C4@hg.openjdk.java.net> Changeset: 2b2818e3386f Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/2b2818e3386f Added tag jdk8-b19 for changeset b73b733214aa ! .hgtags Changeset: dc2ee8b87884 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/dc2ee8b87884 Added tag jdk8-b20 for changeset 2b2818e3386f ! .hgtags Changeset: e67d51254533 Author: ohair Date: 2012-01-09 09:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/e67d51254533 7096063: /META-INF/mimetypes.default missing in jre\lib\resources.jar Reviewed-by: dholmes ! build-defs.xml Changeset: c266cab0e3ff Author: katleman Date: 2012-01-11 16:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c266cab0e3ff Merge Changeset: 8d3df89b0f2d Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/8d3df89b0f2d Added tag jdk8-b21 for changeset c266cab0e3ff ! .hgtags From lana.steuck at oracle.com Wed Jan 18 20:17:13 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 18 Jan 2012 20:17:13 +0000 Subject: hg: jdk8/tl/jaxp: 3 new changesets Message-ID: <20120118201713.20293479C5@hg.openjdk.java.net> Changeset: f052abb8f374 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f052abb8f374 Added tag jdk8-b19 for changeset dffeb62b1a7f ! .hgtags Changeset: d41eeadf5c13 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d41eeadf5c13 Added tag jdk8-b20 for changeset f052abb8f374 ! .hgtags Changeset: cf9d6ec44f89 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/cf9d6ec44f89 Added tag jdk8-b21 for changeset d41eeadf5c13 ! .hgtags From lana.steuck at oracle.com Wed Jan 18 20:17:07 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 18 Jan 2012 20:17:07 +0000 Subject: hg: jdk8/tl/hotspot: 3 new changesets Message-ID: <20120118201718.53D4F479C6@hg.openjdk.java.net> Changeset: fe2c87649981 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fe2c87649981 Added tag jdk8-b19 for changeset 9232e0ecbc2c ! .hgtags Changeset: 9952d1c439d6 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9952d1c439d6 Added tag jdk8-b20 for changeset fe2c87649981 ! .hgtags Changeset: ed621d125d02 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ed621d125d02 Added tag jdk8-b21 for changeset 9952d1c439d6 ! .hgtags From lana.steuck at oracle.com Wed Jan 18 20:17:19 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 18 Jan 2012 20:17:19 +0000 Subject: hg: jdk8/tl/langtools: 6 new changesets Message-ID: <20120118201731.998B6479C7@hg.openjdk.java.net> Changeset: ffd294128a48 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ffd294128a48 Added tag jdk8-b19 for changeset 77b2c066084c ! .hgtags Changeset: 020819eb56d2 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/020819eb56d2 Added tag jdk8-b20 for changeset ffd294128a48 ! .hgtags Changeset: 4e8aa6eca726 Author: lana Date: 2012-01-04 10:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4e8aa6eca726 Merge Changeset: bcb21abf1c41 Author: lana Date: 2012-01-09 19:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bcb21abf1c41 Merge Changeset: 390a7828ae18 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/390a7828ae18 Added tag jdk8-b21 for changeset bcb21abf1c41 ! .hgtags Changeset: f00afa80f1f0 Author: lana Date: 2012-01-18 11:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f00afa80f1f0 Merge From lana.steuck at oracle.com Wed Jan 18 20:18:17 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 18 Jan 2012 20:18:17 +0000 Subject: hg: jdk8/tl/jdk: 20 new changesets Message-ID: <20120118202131.6962A479C8@hg.openjdk.java.net> Changeset: 60dd940eb58e Author: yhuang Date: 2011-12-12 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60dd940eb58e 7003124: In Bulgarian Locale DateFormat is wrong Reviewed-by: naoto, peytoia ! src/share/classes/sun/text/resources/FormatData_bg.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: cd03cd0e0965 Author: mfang Date: 2011-12-15 11:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd03cd0e0965 Merge Changeset: 3778f8577305 Author: katleman Date: 2011-12-28 15:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3778f8577305 Merge Changeset: 80350ee39fa8 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80350ee39fa8 Added tag jdk8-b19 for changeset 3778f8577305 ! .hgtags Changeset: 172d70c50c65 Author: cgruszka Date: 2011-09-15 13:59 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/172d70c50c65 7066713: Separate demos from the bundles on Solaris and Linux Summary: add new license files to demos and samples, new directory for bundling Reviewed-by: katleman, ohair, billyh ! make/common/Release.gmk ! make/common/shared/Defs-control.gmk Changeset: eaf967fd25c5 Author: cgruszka Date: 2011-10-18 14:21 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eaf967fd25c5 7099017: jdk7u2-dev does not build Summary: changes to skip demo/DEMOS_LICENSE and sample/SAMPLES_LICENSE when building OPENJDK Reviewed-by: ohair, billyh ! make/common/Release.gmk Changeset: 39b7f01203c9 Author: cgruszka Date: 2011-11-17 16:57 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39b7f01203c9 Merge Changeset: b64e7263b4fd Author: cgruszka Date: 2011-11-18 01:03 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b64e7263b4fd Merge Changeset: e98869ff9f1e Author: cgruszka Date: 2011-12-05 12:41 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e98869ff9f1e Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: ffa36a6a46f5 Author: cgruszka Date: 2011-12-16 15:01 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ffa36a6a46f5 Merge - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: 5fe1525e6e2c Author: cgruszka Date: 2011-12-23 10:43 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5fe1525e6e2c Merge Changeset: 39e938cd1b82 Author: cgruszka Date: 2012-01-03 14:34 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39e938cd1b82 Merge Changeset: fc050750f8a0 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc050750f8a0 Added tag jdk8-b20 for changeset 39e938cd1b82 ! .hgtags Changeset: 38a318502e19 Author: lana Date: 2012-01-04 10:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/38a318502e19 Merge ! make/common/Release.gmk - test/tools/launcher/DefaultLocaleTest.sh Changeset: 93ab1df09d11 Author: lana Date: 2012-01-09 19:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93ab1df09d11 Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: ddb97d4fa83d Author: ohair Date: 2012-01-04 17:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ddb97d4fa83d 7127104: Build issue with prtconf and zones, also using := to avoid extra execs Reviewed-by: katleman ! make/common/shared/Platform.gmk Changeset: 7c8c16f2c05e Author: ohair Date: 2012-01-09 09:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c8c16f2c05e 7128320: Fix freetype sanity check to make it more generic Reviewed-by: luchsh, katleman Contributed-by: Jonathan Lu ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Demo.gmk ! make/tools/freetypecheck/Makefile Changeset: 664fa4fb0ee4 Author: katleman Date: 2012-01-11 16:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/664fa4fb0ee4 Merge Changeset: dda27c73d8db Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dda27c73d8db Added tag jdk8-b21 for changeset 664fa4fb0ee4 ! .hgtags Changeset: b14e13237498 Author: lana Date: 2012-01-18 11:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b14e13237498 Merge From sean.mullan at oracle.com Wed Jan 18 20:24:16 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 18 Jan 2012 15:24:16 -0500 Subject: Code review request, CR 7093640 Enable TLS 1.1 and TLS 1.2 by default in JSSE client In-Reply-To: <4F0EF973.90503@oracle.com> References: <4F0EF973.90503@oracle.com> Message-ID: <4F172A70.6060609@oracle.com> I haven't reviewed the changes, but since this has potential compatibility impact, this will also require a CCC request. You might want to submit it now, and make any adjustments later based on the code review. --Sean On 01/12/2012 10:17 AM, Xuelei Fan wrote: > Hi, > > webrev: http://cr.openjdk.java.net/~xuelei/7093640/webrev.00/ > > It's time to enable TLS 1.1 and TLS 1.2 in JDK by default. > > There is a known tls-version-number tolerant issue for deployed SSL > servers. That is, some servers cannot work with clients whose TLS > version number is bigger than or equals to TLS 1.0. It only happens to > very very very very old and few servers now. > > In JDK 7, because of known server tls-version-number tolerant issues , > TLS 1.1 and TLS 1.2 is not enabled by default in JSSE client. > > TLS 1.1 is able to avoid the CBC issues in TLS 1.0 and previous > releases; and TLS 1.2 is able to use stronger hash functions. As the > tls-version-number tolerant issues have been decreasing recent years, > and the industry is purchasing to use new TLS versions in order to avoid > CBC attack and comply to new hash policy, it's time for us to consider > enable TLS 1.1 and TLS 1.2 in JSSE client by default. > > I know that because there are a few very old servers refuse to or cannot > upgrade to latest TLS implementations, we may run into a few > compatibility issue because of TLS-version-number tolerant issues. But > what's the right time to make use of the advanced features for most of us? > > It's time to enable TLS 1.1 and TLS 1.2 in JDK by default. > > Please review the the changes. > > Thanks, > Xuelei From joe.darcy at oracle.com Thu Jan 19 00:44:40 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 19 Jan 2012 00:44:40 +0000 Subject: hg: jdk8/tl/langtools: 7130768: Clarify behavior of Element.getEnclosingElements in subtypes Message-ID: <20120119004442.815EC479E3@hg.openjdk.java.net> Changeset: cf2496340fef Author: darcy Date: 2012-01-18 16:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cf2496340fef 7130768: Clarify behavior of Element.getEnclosingElements in subtypes Reviewed-by: mcimadamore, jjg ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/PackageElement.java ! src/share/classes/javax/lang/model/element/TypeElement.java From jim.holmlund at sun.com Thu Jan 19 02:27:52 2012 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Thu, 19 Jan 2012 02:27:52 +0000 Subject: hg: jdk8/tl/langtools: 7131308: Three regression tests fail due to bad fix for 7127924 Message-ID: <20120119022754.7DDE5479E4@hg.openjdk.java.net> Changeset: 99261fc7d95d Author: jjh Date: 2012-01-18 18:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/99261fc7d95d 7131308: Three regression tests fail due to bad fix for 7127924 Reviewed-by: jjg ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java From valerie.peng at oracle.com Thu Jan 19 20:06:58 2012 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Thu, 19 Jan 2012 20:06:58 +0000 Subject: hg: jdk8/tl/jdk: 7092825: javax.crypto.Cipher.Transform.patternCache is synchronizedMap and became scalability bottleneck. Message-ID: <20120119200711.C17CC470A0@hg.openjdk.java.net> Changeset: 313da5d059bf Author: valeriep Date: 2012-01-19 12:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/313da5d059bf 7092825: javax.crypto.Cipher.Transform.patternCache is synchronizedMap and became scalability bottleneck. Summary: Changed patternCache from synchronizedMap to ConcurrentHashMap. Reviewed-by: mullan ! src/share/classes/javax/crypto/Cipher.java From sean.mullan at oracle.com Fri Jan 20 15:37:49 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 20 Jan 2012 10:37:49 -0500 Subject: 7131084 code review request Message-ID: <4F198A4D.8000706@oracle.com> Hi Xuelei, Could you please review the following fix for a regression: http://cr.openjdk.java.net/~mullan/webrevs/7131084/webrev.00/ Some of the test changes are refactoring the code to use generics, try-with-resources, etc. If you have any questions about the specific fix or the bug itself, let me know. Thanks, Sean From joe.darcy at oracle.com Sat Jan 21 01:56:53 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Sat, 21 Jan 2012 01:56:53 +0000 Subject: hg: jdk8/tl/jdk: 4504839: Java libraries should provide support for unsigned integer arithmetic; ... Message-ID: <20120121015731.6C9D7470EE@hg.openjdk.java.net> Changeset: 71200c517524 Author: darcy Date: 2012-01-20 17:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71200c517524 4504839: Java libraries should provide support for unsigned integer arithmetic 4215269: Some Integer.toHexString(int) results cannot be decoded back to an int 6322074: Converting integers to string as if unsigned Reviewed-by: mduigou, emcmanus, flar ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java + test/java/lang/Integer/Unsigned.java + test/java/lang/Long/Unsigned.java From Xuelei.Fan at Oracle.COM Sat Jan 21 10:41:42 2012 From: Xuelei.Fan at Oracle.COM (Xuelei Fan) Date: Sat, 21 Jan 2012 18:41:42 +0800 Subject: 7131084 code review request In-Reply-To: <4F198A4D.8000706@oracle.com> References: <4F198A4D.8000706@oracle.com> Message-ID: <4F1A9666.60404@Oracle.COM> Looks fine to me. Xuelei On 1/20/2012 11:37 PM, Sean Mullan wrote: > Hi Xuelei, > > Could you please review the following fix for a regression: > > http://cr.openjdk.java.net/~mullan/webrevs/7131084/webrev.00/ > > Some of the test changes are refactoring the code to use generics, > try-with-resources, etc. If you have any questions about the specific fix or the > bug itself, let me know. > > Thanks, > Sean From Alan.Bateman at oracle.com Mon Jan 23 12:25:37 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Jan 2012 12:25:37 +0000 Subject: Code review request [JDK 8]: 7132248, sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing In-Reply-To: <4F1D50CB.2000908@Oracle.COM> References: <4F1D50CB.2000908@Oracle.COM> Message-ID: <4F1D51C1.9020304@oracle.com> On 23/01/2012 12:21, Xuelei Fan wrote: > Webrev: http://cr.openjdk.java.net/~xuelei/7132248/webrev.00/ > > In JDK 8, the regression tests of JSSE (HTTP/TLS) run in agentvm > mode. In agentvm mode, multiple threads may share the thread pool. > SunJSSE implementation initialize the SSL/TLS context at the first > time the context get loaded, and will not dynamically change the > context anymore after the initialization. If a test case has > initialized the context, another test case share the same thread will > use the same context. New settings in the later will have no impact on > the context. > > The cause of the bug is that some other test case updated the context, > and CookieHttpsClientTest cannot setup the context as expected. Need > to make the test case run in othervm mode. > > Thanks, > Xuelei This looks fine to me, thanks for jumping on this annoying test failure. -Alan. PS: cc'ing security-dev as I'm guessing you cc'ed serviceabilty-dev in error. From Xuelei.Fan at Oracle.COM Mon Jan 23 12:27:52 2012 From: Xuelei.Fan at Oracle.COM (Xuelei Fan) Date: Mon, 23 Jan 2012 20:27:52 +0800 Subject: Code review request [JDK 8]: 7132248, sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing In-Reply-To: <4F1D51C1.9020304@oracle.com> References: <4F1D50CB.2000908@Oracle.COM> <4F1D51C1.9020304@oracle.com> Message-ID: <4F1D5248.5090607@Oracle.COM> Remove the serviceabilty-dev. Thanks for the quick code review. Xuelei On 1/23/2012 8:25 PM, Alan Bateman wrote: > On 23/01/2012 12:21, Xuelei Fan wrote: >> Webrev: http://cr.openjdk.java.net/~xuelei/7132248/webrev.00/ >> >> In JDK 8, the regression tests of JSSE (HTTP/TLS) run in agentvm >> mode. In agentvm mode, multiple threads may share the thread pool. >> SunJSSE implementation initialize the SSL/TLS context at the first >> time the context get loaded, and will not dynamically change the >> context anymore after the initialization. If a test case has >> initialized the context, another test case share the same thread will >> use the same context. New settings in the later will have no impact >> on the context. >> >> The cause of the bug is that some other test case updated the >> context, and CookieHttpsClientTest cannot setup the context as >> expected. Need to make the test case run in othervm mode. >> >> Thanks, >> Xuelei > This looks fine to me, thanks for jumping on this annoying test failure. > > -Alan. > > PS: cc'ing security-dev as I'm guessing you cc'ed serviceabilty-dev in > error. From xuelei.fan at oracle.com Mon Jan 23 12:45:29 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 23 Jan 2012 12:45:29 +0000 Subject: hg: jdk8/tl/jdk: 7132248: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing Message-ID: <20120123124542.588494712C@hg.openjdk.java.net> Changeset: d383b5d128e3 Author: xuelei Date: 2012-01-23 04:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d383b5d128e3 7132248: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing Reviewed-by: alanb ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java From chris.hegarty at oracle.com Mon Jan 23 13:07:53 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 23 Jan 2012 13:07:53 +0000 Subject: Code review request [JDK 8]: 7132248, sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing In-Reply-To: <4F1D50CB.2000908@Oracle.COM> References: <4F1D50CB.2000908@Oracle.COM> Message-ID: <4F1D5BA9.7070501@oracle.com> Thanks for taking care of this Andrew. -Chris. On 23/01/2012 12:21, Xuelei Fan wrote: > Webrev: http://cr.openjdk.java.net/~xuelei/7132248/webrev.00/ > > In JDK 8, the regression tests of JSSE (HTTP/TLS) run in agentvm mode. > In agentvm mode, multiple threads may share the thread pool. SunJSSE > implementation initialize the SSL/TLS context at the first time the > context get loaded, and will not dynamically change the context anymore > after the initialization. If a test case has initialized the context, > another test case share the same thread will use the same context. New > settings in the later will have no impact on the context. > > The cause of the bug is that some other test case updated the context, > and CookieHttpsClientTest cannot setup the context as expected. Need to > make the test case run in othervm mode. > > Thanks, > Xuelei From sean.mullan at oracle.com Mon Jan 23 18:40:27 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Mon, 23 Jan 2012 18:40:27 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120123184046.6976E4713A@hg.openjdk.java.net> Changeset: 3df0bd3ed880 Author: mullan Date: 2012-01-23 12:17 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3df0bd3ed880 7131084: XMLDSig XPathFilter2Transform regression involving intersect filter Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath2Filter.java ! test/javax/xml/crypto/dsig/KeySelectors.java ! test/javax/xml/crypto/dsig/ValidationTests.java ! test/javax/xml/crypto/dsig/X509KeySelector.java + test/javax/xml/crypto/dsig/data/xmldsig-xfilter2.xml Changeset: 5e1ad6ad41b7 Author: mullan Date: 2012-01-23 13:23 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e1ad6ad41b7 Merge From joe.darcy at oracle.com Mon Jan 23 20:17:44 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 23 Jan 2012 20:17:44 +0000 Subject: hg: jdk8/tl/jdk: 7132338: Use @code friendly idiom for '\' in javadoc Message-ID: <20120123201754.053A04713D@hg.openjdk.java.net> Changeset: 914711cccc60 Author: darcy Date: 2012-01-23 12:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/914711cccc60 7132338: Use @code friendly idiom for '\' in javadoc Reviewed-by: alanb ! src/share/classes/java/io/DataInput.java ! src/share/classes/java/io/LineNumberInputStream.java ! src/share/classes/java/io/RandomAccessFile.java ! src/share/classes/java/io/StreamTokenizer.java ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/util/Properties.java From alan.bateman at oracle.com Tue Jan 24 09:23:06 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 24 Jan 2012 09:23:06 +0000 Subject: hg: jdk8/tl: 7132204: Default testset in JPRT should not run all tests Message-ID: <20120124092307.001B84715A@hg.openjdk.java.net> Changeset: 0f653ee93477 Author: alanb Date: 2012-01-24 09:08 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0f653ee93477 7132204: Default testset in JPRT should not run all tests Reviewed-by: ohair ! make/jprt.properties From alan.bateman at oracle.com Tue Jan 24 09:24:05 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 24 Jan 2012 09:24:05 +0000 Subject: hg: jdk8/tl/jdk: 7132204: Default testset in JPRT should not run all tests Message-ID: <20120124092421.4ABED4715B@hg.openjdk.java.net> Changeset: 237319a01a9a Author: alanb Date: 2012-01-24 09:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/237319a01a9a 7132204: Default testset in JPRT should not run all tests Reviewed-by: ohair ! make/jprt.properties ! test/ProblemList.txt From rickard.backman at oracle.com Tue Jan 24 13:00:42 2012 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Tue, 24 Jan 2012 13:00:42 +0000 Subject: hg: jdk8/tl/jdk: 7132386: makefile support for tracing/Java Flight Recorder framework phase I Message-ID: <20120124130105.1320547160@hg.openjdk.java.net> Changeset: 718bca4e685f Author: rbackman Date: 2012-01-17 16:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/718bca4e685f 7132386: makefile support for tracing/Java Flight Recorder framework phase I Reviewed-by: ohair, dholmes, rottenha Contributed-by: Markus Gronlund , Erik Gahlin , Nils Loodin , Rickard Backman , Staffan Larsen ! make/com/oracle/Makefile + make/com/oracle/jfr/Makefile ! make/common/Defs.gmk ! make/common/Release.gmk From maurizio.cimadamore at oracle.com Tue Jan 24 17:54:26 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 24 Jan 2012 17:54:26 +0000 Subject: hg: jdk8/tl/langtools: 7129801: Merge the two method applicability routines Message-ID: <20120124175432.C36B84716E@hg.openjdk.java.net> Changeset: 51fb17abfc32 Author: mcimadamore Date: 2012-01-24 17:52 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/51fb17abfc32 7129801: Merge the two method applicability routines Summary: Resolve.java and Infer.java should reuse the same method applicability check routine Reviewed-by: dlsmith, jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/InferVarargsArgumentMismatch.java From kumar.x.srinivasan at oracle.com Tue Jan 24 18:02:10 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 24 Jan 2012 18:02:10 +0000 Subject: hg: jdk8/tl/jdk: 7132270: tools/launcher/DefaultLocaleTestRun.java failing (win) Message-ID: <20120124180231.8A5A04716F@hg.openjdk.java.net> Changeset: f64ea40293db Author: ksrini Date: 2012-01-24 09:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f64ea40293db 7132270: tools/launcher/DefaultLocaleTestRun.java failing (win) Reviewed-by: alanb, chegar ! test/tools/launcher/DefaultLocaleTestRun.java ! test/tools/launcher/TestHelper.java From lance.andersen at oracle.com Tue Jan 24 20:13:54 2012 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Tue, 24 Jan 2012 20:13:54 +0000 Subject: hg: jdk8/tl/jdk: 7132879: address Findbugs issue in WebRowSetXmlWriter Message-ID: <20120124201403.CD26347173@hg.openjdk.java.net> Changeset: 303b67074666 Author: lancea Date: 2012-01-24 15:13 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/303b67074666 7132879: address Findbugs issue in WebRowSetXmlWriter Reviewed-by: forax ! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java From bradford.wetmore at oracle.com Tue Jan 24 20:18:15 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Tue, 24 Jan 2012 12:18:15 -0800 Subject: Code review request [JDK 8]: 7132248, sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing In-Reply-To: <4F1D5248.5090607@Oracle.COM> References: <4F1D50CB.2000908@Oracle.COM> <4F1D51C1.9020304@oracle.com> <4F1D5248.5090607@Oracle.COM> Message-ID: <4F1F1207.8020105@oracle.com> Looks good also... Brad On 1/23/2012 4:27 AM, Xuelei Fan wrote: > Remove the serviceabilty-dev. > > Thanks for the quick code review. > > Xuelei > > On 1/23/2012 8:25 PM, Alan Bateman wrote: >> On 23/01/2012 12:21, Xuelei Fan wrote: >>> Webrev: http://cr.openjdk.java.net/~xuelei/7132248/webrev.00/ >>> >>> In JDK 8, the regression tests of JSSE (HTTP/TLS) run in agentvm >>> mode. In agentvm mode, multiple threads may share the thread pool. >>> SunJSSE implementation initialize the SSL/TLS context at the first >>> time the context get loaded, and will not dynamically change the >>> context anymore after the initialization. If a test case has >>> initialized the context, another test case share the same thread will >>> use the same context. New settings in the later will have no impact >>> on the context. >>> >>> The cause of the bug is that some other test case updated the >>> context, and CookieHttpsClientTest cannot setup the context as >>> expected. Need to make the test case run in othervm mode. >>> >>> Thanks, >>> Xuelei >> This looks fine to me, thanks for jumping on this annoying test failure. >> >> -Alan. >> >> PS: cc'ing security-dev as I'm guessing you cc'ed serviceabilty-dev in >> error. > From jim.holmlund at sun.com Tue Jan 24 23:52:32 2012 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Tue, 24 Jan 2012 23:52:32 +0000 Subject: hg: jdk8/tl/langtools: 7126832: com.sun.tools.javac.api.ClientCodeWrapper$WrappedJavaFileManager cannot be cast Message-ID: <20120124235237.28C944717A@hg.openjdk.java.net> Changeset: ac36176b7de0 Author: jjh Date: 2012-01-24 15:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ac36176b7de0 7126832: com.sun.tools.javac.api.ClientCodeWrapper$WrappedJavaFileManager cannot be cast Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/main/Main.java + test/tools/javah/T7126832/T7126832.java + test/tools/javah/T7126832/java.java From jim.holmlund at sun.com Wed Jan 25 00:31:39 2012 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Wed, 25 Jan 2012 00:31:39 +0000 Subject: hg: jdk8/tl/langtools: 7129225: javac fails to run annotation processors when star import of package of gensrc Message-ID: <20120125003141.674D94717B@hg.openjdk.java.net> Changeset: d16b464e742c Author: jjh Date: 2012-01-24 16:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d16b464e742c 7129225: javac fails to run annotation processors when star import of package of gensrc Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/7129225/Anno.java + test/tools/javac/7129225/AnnoProcessor.java + test/tools/javac/7129225/NegTest.ref + test/tools/javac/7129225/TestImportStar.java + test/tools/javac/7129225/TestImportStar.ref From jim.holmlund at sun.com Wed Jan 25 20:20:33 2012 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Wed, 25 Jan 2012 20:20:33 +0000 Subject: hg: jdk8/tl/langtools: 7133314: The regression test for 7129225 fails when run with jtreg -samevm or jtreg -agentvm Message-ID: <20120125202036.616FC4719D@hg.openjdk.java.net> Changeset: 332dfa0f91df Author: jjh Date: 2012-01-25 12:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/332dfa0f91df 7133314: The regression test for 7129225 fails when run with jtreg -samevm or jtreg -agentvm Reviewed-by: jjg ! test/tools/javac/7129225/AnnoProcessor.java ! test/tools/javac/7129225/NegTest.ref ! test/tools/javac/7129225/TestImportStar.java ! test/tools/javac/7129225/TestImportStar.ref From bradford.wetmore at oracle.com Thu Jan 26 05:15:00 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Wed, 25 Jan 2012 21:15:00 -0800 Subject: Code Review: 7126889: Incorrect SSLEngine debug output Message-ID: <4F20E154.6070506@oracle.com> Xuelei (or anyone else available to review this 1-line change), 7126889: Incorrect SSLEngine debug output The JSSE debug information is currently reporting one extra byte being written out, but is not actually doing that. This is just a simple adjustment to correct that error. http://cr.openjdk.java.net/~wetmore/7126889 Both jdk8 and jdk7u are there, the fix is identical. grep'ing System.out debug output in a shell script seemed to be the easiest way to test. Alan/Michael, let me know if you have a better idea. The changes will also be pushed into 5/6/6-open in a separate effort. Brad From yuka.kamiya at oracle.com Thu Jan 26 08:08:38 2012 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Thu, 26 Jan 2012 08:08:38 +0000 Subject: hg: jdk8/tl/jdk: 7017458: (cal) Multithreaded deserialization of Calendar leads to ClassCastException Message-ID: <20120126080847.A0FEA471C1@hg.openjdk.java.net> Changeset: ceab7e149581 Author: peytoia Date: 2012-01-26 17:06 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ceab7e149581 7017458: (cal) Multithreaded deserialization of Calendar leads to ClassCastException Reviewed-by: okutsu ! src/share/classes/java/util/Calendar.java + test/java/util/Calendar/Bug7017458.java From Xuelei.Fan at Oracle.COM Thu Jan 26 10:00:52 2012 From: Xuelei.Fan at Oracle.COM (Xuelei Fan) Date: Thu, 26 Jan 2012 18:00:52 +0800 Subject: Code Review: 7126889: Incorrect SSLEngine debug output In-Reply-To: <4F20E154.6070506@oracle.com> References: <4F20E154.6070506@oracle.com> Message-ID: <4F212454.7060008@Oracle.COM> The fix looks fine to me except some minor comments. 1. The copyright year should be 2012 now. 2. EngineArgs.java There is a resetPos() method in the class, which will reset application positions to original status. In the current fix, the "appRemaining" variable is not reset within the resetPos() method. As a result, after the call of resetPos(), the value of "appRemaining" variable may be not the expected value. For example, EngineArgs args = new EngineArgs(); // suppose the appRemaining value is 5 args.gather(2); int remaining = args.getAppRemaining(); // remaining should be 3; args.resetPos(); remaining = args.getAppRemaining(); // remaining is expected to be 5 // but indeed the value is 3. The fix is OK in that in our implementation, once we reset the position of an instance of EngineArgs, we will abolish the instance and never use it any more. To avoid any miss-use of this class in the future, I would like to have a method comment on resetPos() to talk about the note, or more effort, to reserve the original app remaining value and reset appRemaining to it in resetPos(). Thanks, Xuelei On 1/26/2012 1:15 PM, Brad Wetmore wrote: > Xuelei (or anyone else available to review this 1-line change), > > 7126889: Incorrect SSLEngine debug output > > The JSSE debug information is currently reporting one extra byte being > written out, but is not actually doing that. This is just a simple > adjustment to correct that error. > > http://cr.openjdk.java.net/~wetmore/7126889 > > Both jdk8 and jdk7u are there, the fix is identical. > > grep'ing System.out debug output in a shell script seemed to be the > easiest way to test. Alan/Michael, let me know if you have a better > idea. > > The changes will also be pushed into 5/6/6-open in a separate effort. > > Brad > From rickard.backman at oracle.com Thu Jan 26 13:08:59 2012 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Thu, 26 Jan 2012 13:08:59 +0000 Subject: hg: jdk8/tl/jdk: 7133124: Remove redundant packages from JAR command line Message-ID: <20120126130920.71D86471CB@hg.openjdk.java.net> Changeset: 350971f50949 Author: rbackman Date: 2012-01-26 09:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/350971f50949 7133124: Remove redundant packages from JAR command line Reviewed-by: acorn, alanb, dholmes, rottenha ! make/common/Release.gmk From bradford.wetmore at oracle.com Thu Jan 26 22:58:58 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 26 Jan 2012 14:58:58 -0800 Subject: Code Review: 7126889: Incorrect SSLEngine debug output In-Reply-To: <4F212454.7060008@Oracle.COM> References: <4F20E154.6070506@oracle.com> <4F212454.7060008@Oracle.COM> Message-ID: <4F21DAB2.60504@oracle.com> On 1/26/2012 2:00 AM, Xuelei Fan wrote: > The fix looks fine to me except some minor comments. > > 1. The copyright year should be 2012 now. Egads... > 2. EngineArgs.java > There is a resetPos() method in the class, which will reset application > positions to original status. In the current fix, the "appRemaining" > variable is not reset within the resetPos() method. As a result, after > the call of resetPos(), the value of "appRemaining" variable may be not > the expected value. For example, > EngineArgs args = new EngineArgs(); // suppose the appRemaining value is 5 > args.gather(2); > int remaining = args.getAppRemaining(); // remaining should be 3; > args.resetPos(); > remaining = args.getAppRemaining(); // remaining is expected to be 5 > // but indeed the value is 3. > > The fix is OK in that in our implementation, once we reset the position > of an instance of EngineArgs, we will abolish the instance and never use > it any more. As you noticed, that is only in the error case and this EngineArgs instance is going away very soon, but your point is well taken. > To avoid any miss-use of this class in the future, I would like to have > a method comment on resetPos() to talk about the note, or more effort, > to reserve the original app remaining value and reset appRemaining to it > in resetPos(). We've been working together a long time. That's a comment I would make if I noticed the same thing! ;) Thanks. I also noticed a copy/paste error in the SSLEngineImpl exception code that I've cleaned up. This is a minor change, so I'll probably just check in following JPRT. If you're interested, the update is in the same location: http://cr.openjdk.java.net/~wetmore/7126889 but iteration *.01. Brad > Thanks, > Xuelei > > On 1/26/2012 1:15 PM, Brad Wetmore wrote: >> Xuelei (or anyone else available to review this 1-line change), >> >> 7126889: Incorrect SSLEngine debug output >> >> The JSSE debug information is currently reporting one extra byte being >> written out, but is not actually doing that. This is just a simple >> adjustment to correct that error. >> >> http://cr.openjdk.java.net/~wetmore/7126889 >> >> Both jdk8 and jdk7u are there, the fix is identical. >> >> grep'ing System.out debug output in a shell script seemed to be the >> easiest way to test. Alan/Michael, let me know if you have a better idea. >> >> The changes will also be pushed into 5/6/6-open in a separate effort. >> >> Brad >> > From Xuelei.Fan at Oracle.Com Thu Jan 26 23:56:28 2012 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Fri, 27 Jan 2012 07:56:28 +0800 Subject: Code Review: 7126889: Incorrect SSLEngine debug output In-Reply-To: <4F21DAB2.60504@oracle.com> References: <4F20E154.6070506@oracle.com> <4F212454.7060008@Oracle.COM> <4F21DAB2.60504@oracle.com> Message-ID: <1B9ED3EE-B9C3-4318-AD74-D020C14759EE@Oracle.Com> looks fine to me. Thanks, Xuelei Sent from my iPad On Jan 27, 2012, at 6:58 AM, Brad Wetmore wrote: > > > On 1/26/2012 2:00 AM, Xuelei Fan wrote: >> The fix looks fine to me except some minor comments. >> >> 1. The copyright year should be 2012 now. > > Egads... > >> 2. EngineArgs.java >> There is a resetPos() method in the class, which will reset application >> positions to original status. In the current fix, the "appRemaining" >> variable is not reset within the resetPos() method. As a result, after >> the call of resetPos(), the value of "appRemaining" variable may be not >> the expected value. For example, >> EngineArgs args = new EngineArgs(); // suppose the appRemaining value is 5 >> args.gather(2); >> int remaining = args.getAppRemaining(); // remaining should be 3; >> args.resetPos(); >> remaining = args.getAppRemaining(); // remaining is expected to be 5 >> // but indeed the value is 3. > > >> The fix is OK in that in our implementation, once we reset the position >> of an instance of EngineArgs, we will abolish the instance and never use >> it any more. > > As you noticed, that is only in the error case and this EngineArgs instance is going away very soon, but your point is well taken. > >> To avoid any miss-use of this class in the future, I would like to have >> a method comment on resetPos() to talk about the note, or more effort, >> to reserve the original app remaining value and reset appRemaining to it >> in resetPos(). > > We've been working together a long time. That's a comment I would make if I noticed the same thing! ;) Thanks. > > I also noticed a copy/paste error in the SSLEngineImpl exception code that I've cleaned up. > > This is a minor change, so I'll probably just check in following JPRT. > > If you're interested, the update is in the same location: > > http://cr.openjdk.java.net/~wetmore/7126889 > > but iteration *.01. > > Brad > >> Thanks, >> Xuelei >> >> On 1/26/2012 1:15 PM, Brad Wetmore wrote: >>> Xuelei (or anyone else available to review this 1-line change), >>> >>> 7126889: Incorrect SSLEngine debug output >>> >>> The JSSE debug information is currently reporting one extra byte being >>> written out, but is not actually doing that. This is just a simple >>> adjustment to correct that error. >>> >>> http://cr.openjdk.java.net/~wetmore/7126889 >>> >>> Both jdk8 and jdk7u are there, the fix is identical. >>> >>> grep'ing System.out debug output in a shell script seemed to be the >>> easiest way to test. Alan/Michael, let me know if you have a better idea. >>> >>> The changes will also be pushed into 5/6/6-open in a separate effort. >>> >>> Brad >>> >> From lance.andersen at oracle.com Fri Jan 27 00:42:05 2012 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Fri, 27 Jan 2012 00:42:05 +0000 Subject: hg: jdk8/tl/jdk: 7133815: address the findbug errors in CachedRowSetImpl, SerialStruct, BaseRow, SerialInputImpl, SerialOutputImpl Message-ID: <20120127004215.C6803471E7@hg.openjdk.java.net> Changeset: b518b160607f Author: lancea Date: 2012-01-26 19:41 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b518b160607f 7133815: address the findbug errors in CachedRowSetImpl, SerialStruct, BaseRow, SerialInputImpl, SerialOutputImpl Reviewed-by: forax ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/BaseRow.java ! src/share/classes/javax/sql/rowset/serial/SQLInputImpl.java ! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java From bradford.wetmore at oracle.com Fri Jan 27 01:16:54 2012 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Fri, 27 Jan 2012 01:16:54 +0000 Subject: hg: jdk8/tl/jdk: 7126889: Incorrect SSLEngine debug output Message-ID: <20120127011704.23275471EA@hg.openjdk.java.net> Changeset: 5ee30ab905db Author: wetmore Date: 2012-01-26 17:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ee30ab905db 7126889: Incorrect SSLEngine debug output Reviewed-by: xuelei ! src/share/classes/sun/security/ssl/EngineArgs.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh From masayoshi.okutsu at oracle.com Fri Jan 27 06:50:16 2012 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Fri, 27 Jan 2012 06:50:16 +0000 Subject: hg: jdk8/tl/jdk: 7130335: Problem with timezone in a SimpleDateFormat Message-ID: <20120127065039.955054721C@hg.openjdk.java.net> Changeset: 7aa5ddfa3c9d Author: okutsu Date: 2012-01-27 14:58 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7aa5ddfa3c9d 7130335: Problem with timezone in a SimpleDateFormat Reviewed-by: peytoia ! src/share/classes/java/text/SimpleDateFormat.java + test/java/text/Format/DateFormat/Bug7130335.java From valerie.peng at oracle.com Fri Jan 27 22:40:06 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Fri, 27 Jan 2012 14:40:06 -0800 Subject: Code Review Request for 7136538: typo in test/Makefile under the jdk_security3 target Message-ID: <4F2327C6.7050004@oracle.com> Max, Can you please review a one-line fix for this following trivial bug? 7136538 : typo in test/Makefile under the jdk_security3 target The webrev is at http://cr.openjdk.java.net/~valeriep/7136538/webrev.00/ This typo only occurs in JDK8 version of the file and not in 7u. How it happened is still a mystery as I did a diff between them, oh-well. Thanks, Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Fri Jan 27 22:57:35 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Fri, 27 Jan 2012 14:57:35 -0800 Subject: Code Review Request for 7136538: typo in test/Makefile under the jdk_security3 target In-Reply-To: <4F2327C6.7050004@oracle.com> References: <4F2327C6.7050004@oracle.com> Message-ID: <4F232BDF.5010806@oracle.com> Looks good. brad On 1/27/2012 2:40 PM, Valerie (Yu-Ching) Peng wrote: > Max, > > Can you please review a one-line fix for this following trivial bug? > > 7136538 : typo in test/Makefile under the jdk_security3 target > > > The webrev is at > http://cr.openjdk.java.net/~valeriep/7136538/webrev.00/ > > This typo only occurs in JDK8 version of the file and not in 7u. > How it happened is still a mystery as I did a diff between them, oh-well. > > Thanks, > Valerie From valerie.peng at oracle.com Fri Jan 27 23:15:20 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Fri, 27 Jan 2012 15:15:20 -0800 Subject: Code Review Request for 7136538: typo in test/Makefile under the jdk_security3 target In-Reply-To: <4F232BDF.5010806@oracle.com> References: <4F2327C6.7050004@oracle.com> <4F232BDF.5010806@oracle.com> Message-ID: <4F233008.5040109@oracle.com> Ok, thanks Brad! Valerie On 01/27/12 14:57, Brad Wetmore wrote: > Looks good. > > brad > > > On 1/27/2012 2:40 PM, Valerie (Yu-Ching) Peng wrote: >> Max, >> >> Can you please review a one-line fix for this following trivial bug? >> >> 7136538 : >> typo in test/Makefile under the jdk_security3 target >> >> >> The webrev is at >> http://cr.openjdk.java.net/~valeriep/7136538/webrev.00/ >> >> This typo only occurs in JDK8 version of the file and not in 7u. >> How it happened is still a mystery as I did a diff between them, >> oh-well. >> >> Thanks, >> Valerie From valerie.peng at oracle.com Fri Jan 27 23:26:40 2012 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Fri, 27 Jan 2012 23:26:40 +0000 Subject: hg: jdk8/tl/jdk: 7136538: typo in test/Makefile under the jdk_security3 target Message-ID: <20120127232657.9BF1547241@hg.openjdk.java.net> Changeset: ff24779c147f Author: valeriep Date: 2012-01-27 15:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff24779c147f 7136538: typo in test/Makefile under the jdk_security3 target Summary: Fixed the typo of "secrity". Reviewed-by: wetmore ! test/Makefile From kumar.x.srinivasan at oracle.com Sat Jan 28 18:48:05 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 28 Jan 2012 18:48:05 +0000 Subject: hg: jdk8/tl/jdk: 7127906: (launcher) convert the launcher regression tests to java Message-ID: <20120128184824.5522D4724E@hg.openjdk.java.net> Changeset: 7dbc129d8e5c Author: ksrini Date: 2012-01-28 10:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7dbc129d8e5c 7127906: (launcher) convert the launcher regression tests to java Reviewed-by: darcy, naoto ! test/tools/launcher/Arrrghs.java + test/tools/launcher/ChangeDataModel.java - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java ! test/tools/launcher/DefaultLocaleTestRun.java ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/I18NJarTest.java + test/tools/launcher/I18NTest.java ! test/tools/launcher/MiscTests.java ! test/tools/launcher/Settings.java - test/tools/launcher/SomeException.java ! test/tools/launcher/Test7029048.java ! test/tools/launcher/TestHelper.java - test/tools/launcher/UnicodeCleanup.java ! test/tools/launcher/UnicodeTest.java - test/tools/launcher/UnicodeTest.sh ! test/tools/launcher/UnresolvedExceptions.java - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh From lana.steuck at oracle.com Sun Jan 29 05:58:30 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 29 Jan 2012 05:58:30 +0000 Subject: hg: jdk8/tl: 3 new changesets Message-ID: <20120129055830.D7EDA47257@hg.openjdk.java.net> Changeset: 60d6f64a86b1 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/60d6f64a86b1 Added tag jdk8-b22 for changeset 7ad075c80995 ! .hgtags Changeset: 1a5f1d6b98d6 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1a5f1d6b98d6 Added tag jdk8-b23 for changeset 60d6f64a86b1 ! .hgtags Changeset: bd3fcc98c5d2 Author: lana Date: 2012-01-28 20:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/bd3fcc98c5d2 Merge From lana.steuck at oracle.com Sun Jan 29 05:58:30 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 29 Jan 2012 05:58:30 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20120129055830.D4B4347256@hg.openjdk.java.net> Changeset: 95102fd33418 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/95102fd33418 Added tag jdk8-b22 for changeset cf9d6ec44f89 ! .hgtags Changeset: 7836655e2495 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/7836655e2495 Added tag jdk8-b23 for changeset 95102fd33418 ! .hgtags From lana.steuck at oracle.com Sun Jan 29 05:58:30 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 29 Jan 2012 05:58:30 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20120129055830.D1F4847255@hg.openjdk.java.net> Changeset: 25ce7a000487 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/25ce7a000487 Added tag jdk8-b22 for changeset 8d3df89b0f2d ! .hgtags Changeset: e0d90803439b Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/e0d90803439b Added tag jdk8-b23 for changeset 25ce7a000487 ! .hgtags From lana.steuck at oracle.com Sun Jan 29 05:58:30 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 29 Jan 2012 05:58:30 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20120129055832.93E6047258@hg.openjdk.java.net> Changeset: 5218eb256658 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/5218eb256658 Added tag jdk8-b22 for changeset a11d0062c445 ! .hgtags Changeset: b98f0e6dddf9 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/b98f0e6dddf9 Added tag jdk8-b23 for changeset 5218eb256658 ! .hgtags From lana.steuck at oracle.com Sun Jan 29 05:58:30 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 29 Jan 2012 05:58:30 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20120129055841.74AD347259@hg.openjdk.java.net> Changeset: f6191bad139a Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f6191bad139a Added tag jdk8-b22 for changeset 390a7828ae18 ! .hgtags Changeset: 601ffcc6551d Author: lana Date: 2012-01-24 13:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/601ffcc6551d Merge Changeset: 6c9d21ca92c4 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6c9d21ca92c4 Added tag jdk8-b23 for changeset 601ffcc6551d ! .hgtags Changeset: 7d412606d641 Author: lana Date: 2012-01-28 20:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7d412606d641 Merge From lana.steuck at oracle.com Sun Jan 29 05:58:48 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 29 Jan 2012 05:58:48 +0000 Subject: hg: jdk8/tl/hotspot: 88 new changesets Message-ID: <20120129060149.DB6E24725A@hg.openjdk.java.net> Changeset: 0841c0ec2ed6 Author: amurillo Date: 2011-12-23 15:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0841c0ec2ed6 7123810: new hotspot build - hs23-b10 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3b2b58fb1425 Author: tonyp Date: 2011-12-20 12:59 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3b2b58fb1425 7123165: G1: output during parallel verification can get messed up Summary: Serialize the worker threads that are generating output during parallel heap verification to make sure the output is consistent. Reviewed-by: brutisso, johnc, jmasa ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: d15b458c4225 Author: jmasa Date: 2011-12-20 20:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d15b458c4225 Merge Changeset: 67fdcb391461 Author: tonyp Date: 2011-12-21 07:53 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/67fdcb391461 7119027: G1: use atomics to update RS length / predict time of inc CSet Summary: Make sure that the updates to the RS length and inc CSet predicted time are updated in an MT-safe way. Reviewed-by: brutisso, iveresov ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 441e946dc1af Author: jmasa Date: 2011-12-14 13:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/441e946dc1af 7121618: Change type of number of GC workers to unsigned int. Summary: Change variables representing the number of GC workers to uint from int and size_t. Change the parameter in work(int i) to work(uint worker_id). Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 1cbe7978b021 Author: brutisso Date: 2011-12-21 22:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1cbe7978b021 7113021: G1: automatically enable young gen size auto-tuning when -Xms==-Xmx Summary: Use a percentage of -Xms as min and another percentage of -Xmx as max for the young gen size Reviewed-by: tonyp, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 7faca6dfa2ed Author: jmasa Date: 2011-12-27 12:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7faca6dfa2ed Merge ! src/share/vm/runtime/globals.hpp Changeset: 4ceaf61479fc Author: dcubed Date: 2011-12-22 12:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4ceaf61479fc 7122253: Instrumentation.retransformClasses() leaks class bytes Summary: Change ClassFileParser::parseClassFile() to use the instanceKlass:_cached_class_file_bytes field to avoid leaking the cache. Reviewed-by: coleenp, acorn, poonam ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 4ec93d767458 Author: vladidan Date: 2011-12-26 20:36 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4ec93d767458 Merge Changeset: 3db6ea5ce021 Author: vladidan Date: 2011-12-29 20:09 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3db6ea5ce021 Merge Changeset: 20bfb6d15a94 Author: iveresov Date: 2011-12-27 16:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/20bfb6d15a94 7124829: NUMA: memory leak on Linux with large pages Summary: In os::free_memory() use mmap with the same attributes as for the heap space Reviewed-by: kvn Contributed-by: Aleksey Ignatenko ! 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/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/runtime/os.hpp Changeset: 776173fc2df9 Author: stefank Date: 2011-12-29 07:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/776173fc2df9 7125516: G1: ~ConcurrentMark() frees incorrectly Summary: Replaced the code with a ShouldNotReachHere Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 5ee33ff9b1c4 Author: jmasa Date: 2012-01-03 10:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ee33ff9b1c4 Merge Changeset: 75c0a73eee98 Author: coleenp Date: 2011-11-17 12:53 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/75c0a73eee98 7102776: Pack instanceKlass boolean fields into single u1 field Summary: Reduce class runtime memory usage by packing 4 instanceKlass boolean fields into single u1 field. Save 4-byte for each loaded class. Reviewed-by: dholmes, bobv, phh, twisti, never, coleenp Contributed-by: Jiangli Zhou ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: da4dd142ea01 Author: bobv Date: 2011-11-29 14:44 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/da4dd142ea01 Merge ! src/share/vm/code/dependencies.cpp Changeset: 52b5d32fbfaf Author: coleenp Date: 2011-12-06 18:28 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/52b5d32fbfaf 7117052: instanceKlass::_init_state can be u1 type Summary: Change instanceKlass::_init_state field to u1 type. Reviewed-by: bdelsart, coleenp, dholmes, phh, never Contributed-by: Jiangli Zhou ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: eccc4b1f8945 Author: vladidan Date: 2011-12-07 16:47 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eccc4b1f8945 7050298: ARM: SIGSEGV in JNIHandleBlock::allocate_handle Summary: missing release barrier in Monitor::IUnlock Reviewed-by: dholmes, dice ! src/share/vm/runtime/mutex.cpp Changeset: 2685ea97b89f Author: jiangli Date: 2011-12-09 11:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2685ea97b89f Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp Changeset: 8fdf463085e1 Author: jiangli Date: 2011-12-16 17:33 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8fdf463085e1 Merge Changeset: dca455dea3a7 Author: bdelsart Date: 2011-12-20 12:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dca455dea3a7 7116216: StackOverflow GC crash Summary: GC crash for explicit stack overflow checks after a C2I transition. Reviewed-by: coleenp, never Contributed-by: yang02.wang at sap.com, bertrand.delsart at oracle.com ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp + test/compiler/7116216/LargeFrame.java + test/compiler/7116216/StackOverflow.java Changeset: cd5d8cafcc84 Author: jiangli Date: 2011-12-28 12:15 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd5d8cafcc84 7123315: instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count should be u2 type. Summary: Change instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count to u2 type. Reviewed-by: never, bdelsart, dholmes Contributed-by: Jiangli Zhou ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 05de27e852c4 Author: jiangli Date: 2012-01-04 12:36 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/05de27e852c4 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: b6a04c79ccbc Author: stefank Date: 2012-01-02 10:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b6a04c79ccbc 7125503: Compiling collectedHeap.cpp fails with -Werror=int-to-pointer-cast with g++ 4.6.1 Summary: Used uintptr_t and void* for all the casts and checks in test_is_in. Reviewed-by: tonyp, jmasa ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: 4753e3dda3c8 Author: jmasa Date: 2012-01-04 07:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4753e3dda3c8 Merge Changeset: 2ee4167627a3 Author: jmasa Date: 2012-01-05 21:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2ee4167627a3 Merge Changeset: 7ab5f6318694 Author: phh Date: 2012-01-01 11:17 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ab5f6318694 7125934: Add a fast unordered timestamp capability to Hotspot on x86/x64 Summary: Add rdtsc detection and inline generation. Reviewed-by: kamg, dholmes Contributed-by: karen.kinnear at oracle.com ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/os_bsd_x86.inline.hpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp + src/os_cpu/linux_x86/vm/os_linux_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp + src/os_cpu/solaris_x86/vm/os_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/solaris_x86/vm/solaris_x86_64.il ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp + src/os_cpu/windows_x86/vm/os_windows_x86.inline.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp + src/share/vm/runtime/os_ext.hpp Changeset: b16494a69d3d Author: phh Date: 2012-01-03 15:11 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b16494a69d3d 7126185: Clean up lasterror handling, add os::get_last_error() Summary: Add os::get_last_error(), replace getLastErrorString() by os::lasterror() in os_windows.cpp. Reviewed-by: kamg, dholmes Contributed-by: erik.gahlin at oracle.com ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp Changeset: 5b58979183f9 Author: dcubed Date: 2012-01-05 06:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5b58979183f9 7127032: fix for 7122253 adds a JvmtiThreadState earlier than necessary Summary: Use JavaThread::jvmti_thread_state() instead of JvmtiThreadState::state_for(). Reviewed-by: coleenp, poonam, acorn ! src/share/vm/classfile/classFileParser.cpp Changeset: 8a63c6323842 Author: fparain Date: 2012-01-05 07:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8a63c6323842 7125594: C-heap growth issue in ThreadService::find_deadlocks_at_safepoint Reviewed-by: sspitsyn, dcubed, mchung, dholmes ! src/share/vm/services/threadService.cpp Changeset: 2e0ef19fc891 Author: phh Date: 2012-01-05 17:14 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2e0ef19fc891 7126480: Make JVM start time in milliseconds since the Java epoch available Summary: Expose existing Management::_begin_vm_creation_time via new accessor Management::begin_vm_creation_time(). Reviewed-by: acorn, dcubed ! src/share/vm/services/management.hpp Changeset: 66259eca2bf7 Author: phh Date: 2012-01-05 17:16 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/66259eca2bf7 Merge Changeset: 2b3acb34791f Author: dcubed Date: 2012-01-06 16:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2b3acb34791f Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/os.hpp Changeset: abcceac2f7cd Author: iveresov Date: 2011-12-12 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/abcceac2f7cd 7119730: Tiered: SIGSEGV in AdvancedThresholdPolicy::is_method_profiled(methodOop) Summary: Added handles for references to methods in select_task() Reviewed-by: twisti, kvn ! src/share/vm/runtime/advancedThresholdPolicy.cpp Changeset: 7bca37d28f32 Author: roland Date: 2011-12-13 10:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7bca37d28f32 7114106: C1: assert(goto_state->is_same(sux_state)) failed: states must match now Summary: fix C1's CEE to take inlining into account when the stacks in states are compared. Reviewed-by: iveresov, never ! src/share/vm/c1/c1_Optimizer.cpp Changeset: d725f0affb1a Author: iveresov Date: 2011-12-13 17:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d725f0affb1a 7121111: -server -Xcomp -XX:+TieredCompilation does not invoke C2 compiler Summary: Exercise C2 more in tiered mode with Xcomp Reviewed-by: kvn, never ! src/share/vm/runtime/arguments.cpp Changeset: 127b3692c168 Author: kvn Date: 2011-12-14 14:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/127b3692c168 7116452: Add support for AVX instructions Summary: Added support for AVX extension to the x86 instruction set. Reviewed-by: never ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/runtime/globals.hpp Changeset: 669f6a7d5b70 Author: never Date: 2011-12-19 14:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/669f6a7d5b70 7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type Reviewed-by: kvn ! src/share/vm/opto/compile.cpp Changeset: 65149e74c706 Author: kvn Date: 2011-12-20 00:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/65149e74c706 7121648: Use 3-operands SIMD instructions on x86 with AVX Summary: Use 3-operands SIMD instructions in C2 generated code for machines with AVX. Reviewed-by: never ! make/bsd/makefiles/adlc.make ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! make/windows/makefiles/adlc.make ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp + src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/matcher.cpp Changeset: 069ab3f976d3 Author: stefank Date: 2011-12-07 11:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/069ab3f976d3 7118863: Move sizeof(klassOopDesc) into the *Klass::*_offset_in_bytes() functions Summary: Moved sizeof(klassOopDesc), changed the return type to ByteSize and removed the _in_bytes suffix. Reviewed-by: never, bdelsart, coleenp, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassOop.hpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/shark/sharkIntrinsics.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: 1dc233a8c7fe Author: roland Date: 2011-12-20 16:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1dc233a8c7fe 7121140: Allocation paths require explicit memory synchronization operations for RMO systems Summary: adds store store barrier after initialization of header and body of objects. Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.hpp Changeset: e5ac210043cd Author: roland Date: 2011-12-22 10:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e5ac210043cd 7123108: C1: assert(if_state != NULL) failed: states do not match up Summary: In CEE, ensure if and common successor state are at the same inline level Reviewed-by: never ! src/share/vm/c1/c1_Optimizer.cpp + test/compiler/7123108/Test7123108.java Changeset: b642b49f9738 Author: roland Date: 2011-12-23 09:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b642b49f9738 7123253: C1: in store check code, usage of registers may be incorrect Summary: fix usage of input register in assembly code for store check. Reviewed-by: never ! src/share/vm/c1/c1_LIR.cpp Changeset: 40c2484c09e1 Author: kvn Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/40c2484c09e1 7110832: ctw/.../org_apache_avalon_composition_util_StringHelper crashes the VM Summary: Distance is too large for one short branch in string_indexofC8(). Reviewed-by: iveresov ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp Changeset: d12a66fa3820 Author: kvn Date: 2011-12-27 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d12a66fa3820 7123954: Some CTW test crash with SIGSEGV Summary: Correct Allocate expansion code to preserve i_o when only slow call is generated. Reviewed-by: iveresov ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/macro.cpp Changeset: 8940fd98d540 Author: kvn Date: 2011-12-29 11:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8940fd98d540 Merge ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 9c87bcb3b4dd Author: kvn Date: 2011-12-30 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9c87bcb3b4dd 7125879: assert(proj != NULL) failed: must be found Summary: Leave i_o attached to slow allocation call when there are no i_o users after the call. Reviewed-by: iveresov, twisti ! src/share/vm/opto/macro.cpp + test/compiler/7125879/Test7125879.java Changeset: 1cb50d7a9d95 Author: iveresov Date: 2012-01-05 17:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1cb50d7a9d95 7119294: Two command line options cause JVM to crash Summary: Setup thread register in MacroAssembler::incr_allocated_bytes() on x64 Reviewed-by: kvn ! src/cpu/x86/vm/assembler_x86.cpp Changeset: 22cee0ee8927 Author: kvn Date: 2012-01-06 20:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/22cee0ee8927 Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parseHelper.cpp Changeset: 8f8b94305aff Author: dcubed Date: 2012-01-11 19:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8f8b94305aff 7129240: backout fix for 7102776 until 7128770 is resolved Reviewed-by: phh, bobv, coleenp, dcubed Contributed-by: Jiangli Zhou ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 4f25538b54c9 Author: fparain Date: 2012-01-09 10:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4f25538b54c9 7120511: Add diagnostic commands Reviewed-by: acorn, phh, dcubed, sspitsyn ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/management.cpp Changeset: 865e0817f32b Author: kamg Date: 2012-01-10 15:47 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/865e0817f32b Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: efdf6985a3a2 Author: kamg Date: 2012-01-12 09:59 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/efdf6985a3a2 Merge Changeset: 5da7201222d5 Author: kvn Date: 2012-01-07 10:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5da7201222d5 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM Summary: Change yank_if_dead() to recursive method to remove all dead inputs. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/postaloc.cpp Changeset: e9a5e0a812c8 Author: kvn Date: 2012-01-07 13:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e9a5e0a812c8 7125896: Eliminate nested locks Summary: Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object. Reviewed-by: never, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 35acf8f0a2e4 Author: kvn Date: 2012-01-10 18:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/35acf8f0a2e4 7128352: assert(obj_node == obj) failed Summary: Compare uncasted object nodes. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/subnode.cpp ! test/compiler/7116216/StackOverflow.java Changeset: c8d8e124380c Author: kvn Date: 2012-01-12 12:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c8d8e124380c 7064302: JDK7 build 147 crashed after testing my java 6-compiled web app Summary: Don't split CMove node if it's control edge is different from split region. Reviewed-by: never ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp Changeset: 31a5b9aad4bc Author: jrose Date: 2012-01-13 00:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/31a5b9aad4bc Merge ! src/share/vm/runtime/arguments.cpp Changeset: bacb651cf5bf Author: tonyp Date: 2012-01-05 05:54 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bacb651cf5bf 7113006: G1: excessive ergo output when an evac failure happens Summary: Introduce a flag that is set when a heap expansion attempt during a GC fails so that we do not consantly attempt to expand the heap when it's going to fail anyway. This not only prevents the excessive ergo output (which is generated when a region allocation fails) but also avoids excessive and ultimately unsuccessful expansion attempts. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 5fd354a959c5 Author: jmasa Date: 2012-01-05 21:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5fd354a959c5 Merge Changeset: 023652e49ac0 Author: johnc Date: 2011-12-23 11:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/023652e49ac0 7121496: G1: do the per-region evacuation failure handling work in parallel Summary: Parallelize the removal of self forwarding pointers etc. by wrapping in a HeapRegion closure, which is then wrapped inside an AbstractGangTask. Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp + src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 02838862dec8 Author: tonyp Date: 2012-01-07 00:43 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/02838862dec8 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array Summary: Store the "next chunk start index" in the length field of the to-space object, instead of the from-space object, so that we can always reliably read the size of all from-space objects. Reviewed-by: johnc, ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 97c00e21fecb Author: tonyp Date: 2012-01-09 23:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/97c00e21fecb 7125281: G1: heap expansion code is replicated Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 1d6185f732aa Author: brutisso Date: 2012-01-10 20:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1d6185f732aa 7128532: G1: Change default value of G1DefaultMaxNewGenPercent to 80 Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 2ace1c4ee8da Author: tonyp Date: 2012-01-10 18:58 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2ace1c4ee8da 6888336: G1: avoid explicitly marking and pushing objects in survivor spaces Summary: This change simplifies the interaction between GC and concurrent marking. By disabling survivor spaces during the initial-mark pause we don't need to propagate marks of objects we copy during each GC (since we never need to copy an explicitly marked object). Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp Changeset: 9d4f4a1825e4 Author: brutisso Date: 2012-01-13 01:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9d4f4a1825e4 Merge Changeset: 5acd82522540 Author: brutisso Date: 2012-01-13 06:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5acd82522540 Merge Changeset: b0ff910edfc9 Author: kvn Date: 2012-01-12 14:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b0ff910edfc9 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed Summary: Do not common BoxLock nodes and avoid creating phis of boxes. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/parse1.cpp Changeset: f4d8930a45b9 Author: jrose Date: 2012-01-13 00:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f4d8930a45b9 Merge Changeset: 89d0a5d40008 Author: kvn Date: 2012-01-13 12:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/89d0a5d40008 7129618: assert(obj_node->eqv_uncast(obj),""); Summary: Relax verification and locks elimination checks for new implementation (EliminateNestedLocks). Reviewed-by: iveresov ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/macro.cpp Changeset: e504fd26c073 Author: kvn Date: 2012-01-13 14:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e504fd26c073 Merge Changeset: 513351373923 Author: amurillo Date: 2012-01-14 00:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/513351373923 Merge Changeset: 24727fb37561 Author: amurillo Date: 2012-01-14 00:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/24727fb37561 Added tag hs23-b10 for changeset 513351373923 ! .hgtags Changeset: 338d438ee229 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/338d438ee229 Added tag jdk8-b22 for changeset 24727fb37561 ! .hgtags Changeset: 4e80db53c323 Author: amurillo Date: 2012-01-14 00:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4e80db53c323 7129512: new hotspot build - hs23-b11 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 94ec88ca68e2 Author: phh Date: 2012-01-11 17:34 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/94ec88ca68e2 7115199: Add event tracing hooks and Java Flight Recorder infrastructure Summary: Added a nop tracing infrastructure, JFR makefile changes and other infrastructure used only by JFR. Reviewed-by: acorn, sspitsyn Contributed-by: markus.gronlund at oracle.com ! make/Makefile ! make/bsd/makefiles/vm.make ! make/defs.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! make/windows/build.bat ! make/windows/create_obj_files.sh ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jni.cpp + src/share/vm/prims/jniExport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vm_operations.hpp + src/share/vm/trace/traceEventTypes.hpp + src/share/vm/trace/traceMacros.hpp + src/share/vm/trace/tracing.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 4f3ce9284781 Author: phh Date: 2012-01-11 17:58 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4f3ce9284781 Merge ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp Changeset: f1cd52d6ce02 Author: kamg Date: 2012-01-17 10:16 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f1cd52d6ce02 Merge Changeset: d7e3846464d0 Author: zgu Date: 2012-01-17 13:08 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d7e3846464d0 7071311: Decoder enhancement Summary: Made decoder thread-safe Reviewed-by: coleenp, kamg - src/os/bsd/vm/decoder_bsd.cpp + src/os/bsd/vm/decoder_machO.cpp + src/os/bsd/vm/decoder_machO.hpp ! src/os/linux/vm/decoder_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/decoder_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/decoder_windows.cpp + src/os/windows/vm/decoder_windows.hpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp + src/share/vm/utilities/decoder_elf.cpp + src/share/vm/utilities/decoder_elf.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/elfStringTable.cpp ! src/share/vm/utilities/elfStringTable.hpp ! src/share/vm/utilities/elfSymbolTable.cpp ! src/share/vm/utilities/elfSymbolTable.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 6520f9861937 Author: kamg Date: 2012-01-17 21:25 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6520f9861937 Merge Changeset: db18ca98d237 Author: zgu Date: 2012-01-18 11:45 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/db18ca98d237 7131050: fix for "7071311 Decoder enhancement" does not build on MacOS X Summary: Decoder API changes did not reflect in os_bsd Reviewed-by: kamg, dcubed ! src/os/bsd/vm/os_bsd.cpp Changeset: eaa9557116a2 Author: bdelsart Date: 2012-01-18 16:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eaa9557116a2 7120448: Fix FP values for compiled frames in frame::describe Summary: fix for debug method frame::describe Reviewed-by: never, kvn ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp Changeset: 15d394228cfa Author: jrose Date: 2012-01-19 13:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/15d394228cfa 7111138: delete the obsolete flag -XX:+UseRicochetFrames Reviewed-by: dholmes, bdelsart, kvn, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/zero/vm/methodHandles_zero.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 898522ae3c32 Author: iveresov Date: 2012-01-19 10:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/898522ae3c32 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) Summary: Fix exception handler stub size, enable guarantees to check for the correct deopt and exception stub sizes in the future Reviewed-by: kvn, never, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 469e0a46f2fe Author: jrose Date: 2012-01-19 17:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/469e0a46f2fe Merge Changeset: 50d9b7a0072c Author: jrose Date: 2012-01-19 18:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/50d9b7a0072c Merge Changeset: dcc292399a39 Author: amurillo Date: 2012-01-20 16:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dcc292399a39 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: e850d8e7ea54 Author: amurillo Date: 2012-01-20 16:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e850d8e7ea54 Added tag hs23-b11 for changeset dcc292399a39 ! .hgtags Changeset: 6edfe6e42a68 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6edfe6e42a68 Added tag jdk8-b23 for changeset e850d8e7ea54 ! .hgtags From lana.steuck at oracle.com Sun Jan 29 05:59:07 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 29 Jan 2012 05:59:07 +0000 Subject: hg: jdk8/tl/jdk: 23 new changesets Message-ID: <20120129060256.0A9F54725B@hg.openjdk.java.net> Changeset: 76bfd08d8cc5 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76bfd08d8cc5 Added tag jdk8-b22 for changeset dda27c73d8db ! .hgtags Changeset: 44bd765c22f4 Author: prr Date: 2012-01-13 13:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44bd765c22f4 7127827: JRE8: javaws fails to launch on oracle linux due to XRender Reviewed-by: bae, jgodinez ! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java Changeset: b566004bcb1a Author: dbuck Date: 2012-01-16 11:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b566004bcb1a 7083621: Add fontconfig file for OEL6 and rename RH/O EL 5 file so that it is picked up for all 5.x updates Reviewed-by: bae, prr ! make/sun/awt/Makefile Changeset: 397667460892 Author: lana Date: 2012-01-18 11:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/397667460892 Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: e0f94b9c53a8 Author: alexsch Date: 2012-01-10 15:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0f94b9c53a8 7110815: closed/javax/swing/JSplitPane/4885629/bug4885629.java unstable on MacOS Reviewed-by: kizune + test/javax/swing/JSplitPane/4885629/bug4885629.java Changeset: 79d14e328670 Author: alexsch Date: 2012-01-10 17:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79d14e328670 6505523: NullPointerException in BasicTreeUI when a node is removed by expansion listener Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java + test/javax/swing/JTree/6505523/bug6505523.java Changeset: ce32a4e1be1d Author: alexsch Date: 2012-01-13 12:39 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce32a4e1be1d 7121765: closed/javax/swing/JTextArea/4697612/bug4697612.java fails on MacOS on Aqua L&F Reviewed-by: rupashka + test/javax/swing/JTextArea/4697612/bug4697612.java + test/javax/swing/JTextArea/4697612/bug4697612.txt Changeset: 59b8875949e1 Author: malenkov Date: 2012-01-16 18:28 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59b8875949e1 7122740: PropertyDescriptor Performance Slow Reviewed-by: rupashka ! src/share/classes/com/sun/beans/TypeResolver.java Changeset: 3e9d35e6ee4f Author: denis Date: 2012-01-17 19:09 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e9d35e6ee4f 7110590: DnDMerlinQLTestsuite_DnDJTextArea test fails with an java.awt.dnd.InvalidDnDOperationException Reviewed-by: art ! src/share/classes/java/awt/AWTKeyStroke.java Changeset: 89bc9d08fe82 Author: anthony Date: 2012-01-18 19:09 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89bc9d08fe82 7130662: GTK file dialog crashes with a NPE Summary: Guard adding a back slash to the directory name with an if (!= null) check Reviewed-by: anthony, art Contributed-by: Matt ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java Changeset: fe1278123fbb Author: lana Date: 2012-01-18 11:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe1278123fbb Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: 4d8b49a45cff Author: lana Date: 2012-01-18 20:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d8b49a45cff Merge Changeset: e6614f361127 Author: lana Date: 2012-01-18 20:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6614f361127 Merge - test/java/io/File/BlockIsDirectory.java Changeset: 227fcf5d0bec Author: lana Date: 2012-01-24 13:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/227fcf5d0bec Merge - test/java/io/File/BlockIsDirectory.java Changeset: db189e2f3cdb Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db189e2f3cdb 7117167: Misc warnings in java.lang.invoke and sun.invoke.* Reviewed-by: smarks ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/Wrapper.java ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/ClassValueTest.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/MethodTypeTest.java ! test/java/lang/invoke/PermuteArgsTest.java ! test/java/lang/invoke/RicochetTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java ! test/sun/invoke/util/ValueConversionsTest.java Changeset: 01014596ada1 Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01014596ada1 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init Summary: Use correct access token for unreflecting MHs where setAccessible(true) Reviewed-by: never, twisti ! src/share/classes/java/lang/invoke/MethodHandles.java Changeset: 92d2cba30f08 Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92d2cba30f08 7030453: JSR 292 ClassValue.get method is too slow Summary: Implement ClassValue cooperatively with Class like ThreadLocal with Thread. Reviewed-by: twisti, mduigou ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassValue.java ! test/java/lang/invoke/ClassValueTest.java Changeset: 81a2629aa2a2 Author: amurillo Date: 2012-01-20 14:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81a2629aa2a2 Merge Changeset: 954a1c535730 Author: amurillo Date: 2012-01-25 12:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/954a1c535730 Merge - test/java/io/File/BlockIsDirectory.java Changeset: d3b334e376d3 Author: mr Date: 2012-01-23 12:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d3b334e376d3 7110396: Sound code fails to build with gcc 4.6 on multiarch Linux systems Reviewed-by: ohair ! make/javax/sound/jsoundalsa/Makefile Changeset: 54202e0148ec Author: katleman Date: 2012-01-25 13:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/54202e0148ec Merge Changeset: 34029a0c69bb Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/34029a0c69bb Added tag jdk8-b23 for changeset 54202e0148ec ! .hgtags Changeset: 7a25b72b3644 Author: lana Date: 2012-01-28 20:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a25b72b3644 Merge From chris.hegarty at oracle.com Mon Jan 30 14:07:39 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 30 Jan 2012 14:07:39 +0000 Subject: hg: jdk8/tl/jdk: 7132378: Race in FutureTask if used with explicit set ( not Runnable ) Message-ID: <20120130140758.691934728A@hg.openjdk.java.net> Changeset: f9fb8c4b4550 Author: dl Date: 2012-01-30 11:44 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f9fb8c4b4550 7132378: Race in FutureTask if used with explicit set ( not Runnable ) Reviewed-by: chegar, dholmes ! src/share/classes/java/util/concurrent/FutureTask.java + test/java/util/concurrent/FutureTask/DoneTimedGetLoops.java + test/java/util/concurrent/FutureTask/ExplicitSet.java From neil.richards at ngmr.net Tue Jan 31 09:51:24 2012 From: neil.richards at ngmr.net (neil.richards at ngmr.net) Date: Tue, 31 Jan 2012 09:51:24 +0000 Subject: hg: jdk8/tl/jdk: 7123229: (coll) EnumMap.containsValue(null) returns true Message-ID: <20120131095153.AD178472A8@hg.openjdk.java.net> Changeset: 863a20b0bf08 Author: ngmr Date: 2012-01-10 00:07 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/863a20b0bf08 7123229: (coll) EnumMap.containsValue(null) returns true Summary: java.util.EnumMap.NULL equals() must only be true for itself Reviewed-by: alanb, mduigou Contributed-by: Neil Richards ! src/share/classes/java/util/EnumMap.java + test/java/util/EnumMap/UniqueNullValue.java From neil.richards at ngmr.net Tue Jan 31 10:33:45 2012 From: neil.richards at ngmr.net (neil.richards at ngmr.net) Date: Tue, 31 Jan 2012 10:33:45 +0000 Subject: hg: jdk8/tl/jdk: 7133301: (process) UNIXProcess_md.c should include sys/wait.h rather than wait.h Message-ID: <20120131103407.6E9E0472AC@hg.openjdk.java.net> Changeset: 13978750cb87 Author: ngmr Date: 2012-01-31 10:31 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13978750cb87 7133301: (process) UNIXProcess_md.c should include sys/wait.h rather than wait.h Reviewed-by: alanb Contributed-by: Jonathan Lu ! src/solaris/native/java/lang/UNIXProcess_md.c From fweimer at bfk.de Tue Jan 31 13:47:59 2012 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 31 Jan 2012 13:47:59 +0000 Subject: Fix for: 6415637: PKCS#12 key stores with empty passwords Message-ID: <82aa54dlv4.fsf@mid.bfk.de> I've ported my previous patch to fix bug 6415637 to the current jdk8-tl forrest. There are two related changes (quoting from the initial submission): 1. The password and salt expansion resulted in a division by zero for empty password strings. 2. Practically speaking, there are two different ways of deriving keys from an empty passphrase: the terminating NUL character is required by the specification, but is left out by some implementations (including OpenJDK if the first bug is fixed). OpenSSL tries to decrypt with both encodings, and the patch implements that as well. It is difficult to properly implement the retry behavior without changing any interfaces, so this patch uses "\0" for the password *without* a NUL terminator. This is a bit confusing, but it ensures that passing an empty string as the password creates a PKCS#12 store which is compliant with the specification. Because of the division of zero issue, the second change does not actually modify visible behavior. To my knowledge, there is now an OCA which covers this change. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -------------- next part -------------- A non-text attachment was scrubbed... Name: 6415637.diff Type: text/x-diff Size: 26875 bytes Desc: not available URL: From staffan.larsen at oracle.com Tue Jan 31 15:48:13 2012 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Tue, 31 Jan 2012 15:48:13 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120131154836.61930472B5@hg.openjdk.java.net> Changeset: 431bc327f34a Author: sla Date: 2012-01-31 10:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/431bc327f34a 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms Summary: Make sure HotSpot and JDK looks for well-known files in the same location Reviewed-by: dholmes, dsamersoff ! src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java ! src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java ! test/ProblemList.txt Changeset: 663a6333105d Author: sla Date: 2012-01-31 04:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/663a6333105d Merge