From sean.mullan at oracle.com Sat Oct 1 16:19:44 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Sat, 01 Oct 2011 12:19:44 -0400 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4E86073D.9050101@gmx.de> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> <4E5E8AE3.3070402@gmx.de> <4E5FE753.2010705@oracle.com> <4E606D1D.6050509@gmx.de> <4E613565.1080801@oracle.com> <4E625E14.9060101@gmx.de> <4E67AF3D.2090609@oracle.com> <4E68FFBD.2030601@gmx.de> <4E6A13A2.2020503@gmx.de> <4E74F05D.7090806@gmx.de> <4E7CD5F8.9000501@oracle.com> <4E7DA91C.2000600@gmx.de> <4E81EDE6.9050205@oracle.com> <4E82A437.30907@gmx.de> <4E86073D.9050101@gmx.de> Message-ID: <4E873DA0.5050906@oracle.com> On 9/30/11 2:15 PM, Sebastian Sickelmann wrote: >>> I think I know the reason. If you allow initCause to be called when a >>> cause is >>> not initially provided, then getCause will still return null, which >>> seems wrong. >>> >> getCause() of Throwable and all classes that doesn't had a chaining >> before >> Throwable introduces it, doing this excact this way. Whats wrong on this? >> >> return (cause==this ? null : cause); // Where the initial >> value(uninitialied) of cause is this. > Does this make sense? I actually not sure i understand you right. The following code: KeySelectorException kse = new KeySelectorException("foo"); kse.initCause(new Exception("bar")); System.out.println(kse.getCause()); prints null as the cause, even though initCause was subsequently called. Do you see my concern? > http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html Thanks! --Sean From sebastian.sickelmann at gmx.de Sun Oct 2 19:49:14 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Sun, 02 Oct 2011 21:49:14 +0200 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4E873DA0.5050906@oracle.com> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> <4E5E8AE3.3070402@gmx.de> <4E5FE753.2010705@oracle.com> <4E606D1D.6050509@gmx.de> <4E613565.1080801@oracle.com> <4E625E14.9060101@gmx.de> <4E67AF3D.2090609@oracle.com> <4E68FFBD.2030601@gmx.de> <4E6A13A2.2020503@gmx.de> <4E74F05D.7090806@gmx.de> <4E7CD5F8.9000501@oracle.com> <4E7DA91C.2000600@gmx.de> <4E81EDE6.9050205@oracle.com> <4E82A437.30907@gmx.de> <4E86073D.9050101@gmx.de> <4E873DA0.5050906@oracle.com> Message-ID: <4E88C03A.90904@gmx.de> Am 01.10.2011 18:19, schrieb Sean Mullan: > On 9/30/11 2:15 PM, Sebastian Sickelmann wrote: >>>> I think I know the reason. If you allow initCause to be called when a >>>> cause is >>>> not initially provided, then getCause will still return null, which >>>> seems wrong. >>>> >>> getCause() of Throwable and all classes that doesn't had a chaining >>> before >>> Throwable introduces it, doing this excact this way. Whats wrong on this? >>> >>> return (cause==this ? null : cause); // Where the initial >>> value(uninitialied) of cause is this. >> Does this make sense? I actually not sure i understand you right. > The following code: > > KeySelectorException kse = new KeySelectorException("foo"); > kse.initCause(new Exception("bar")); > System.out.println(kse.getCause()); > > prints null as the cause, even though initCause was subsequently called. Do you > see my concern? This is one of the places in code which must be changes to match the initCause behavoir of Throwable. I have done it here: http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_5/index.html But is this the best way? Or should we just follow the other Exceptions and start an seperate discussion on this with core-libs-dev? >> http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html > Thanks! > --Sean > From chris.hegarty at oracle.com Tue Oct 4 15:12:21 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 04 Oct 2011 15:12:21 +0000 Subject: hg: jdk8/tl/jdk: 6953455: CookieStore.add() cannot handle null URI parameter, contrary to the API Message-ID: <20111004151240.D32BB47BC1@hg.openjdk.java.net> Changeset: 74f5fef1d961 Author: chegar Date: 2011-10-04 13:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74f5fef1d961 6953455: CookieStore.add() cannot handle null URI parameter, contrary to the API Reviewed-by: chegar, mduigou Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/java/net/InMemoryCookieStore.java + test/java/net/CookieHandler/NullUriCookieTest.java From chris.hegarty at oracle.com Tue Oct 4 16:52:58 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 04 Oct 2011 16:52:58 +0000 Subject: hg: jdk8/tl/jdk: 7095949: java/net/URLConnection/RedirectLimit.java and Redirect307Test fail intermittently Message-ID: <20111004165316.BF71647BC6@hg.openjdk.java.net> Changeset: 24741fe639a8 Author: chegar Date: 2011-10-04 16:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/24741fe639a8 7095949: java/net/URLConnection/RedirectLimit.java and Redirect307Test fail intermittently Reviewed-by: alanb ! test/java/net/URLConnection/Redirect307Test.java ! test/java/net/URLConnection/RedirectLimit.java From masayoshi.okutsu at oracle.com Wed Oct 5 06:23:52 2011 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Wed, 05 Oct 2011 06:23:52 +0000 Subject: hg: jdk8/tl/jdk: 7092679: (tz) Java getting wrong timezone/DST info on Solaris 11; ... Message-ID: <20111005062411.EF7E847BEC@hg.openjdk.java.net> Changeset: 2bc80ba6f4a4 Author: okutsu Date: 2011-10-05 15:13 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2bc80ba6f4a4 7092679: (tz) Java getting wrong timezone/DST info on Solaris 11 6984762: Invalid close of file descriptor '-1' in findZoneinfoFile Reviewed-by: coffeys, ohair, naoto, peytoia ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/java/java/Makefile ! src/solaris/native/java/util/TimeZone_md.c From vincent.x.ryan at oracle.com Wed Oct 5 13:54:36 2011 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 05 Oct 2011 14:54:36 +0100 Subject: code review request: 7094377 Com.sun.jndi.ldap.read.timeout doesn't work with ldaps. Message-ID: <4E8C619C.6020900@oracle.com> Please review a fix for: 7094377 Com.sun.jndi.ldap.read.timeout doesn't work with ldaps. The webrev is available at: http://cr.openjdk.java.net/~vinnie/7094377/webrev.00/ To ensure that LDAP timeouts work correctly on an LDAP over SSL connection, the LDAP connect timeout should include the SSL handshake phase that takes place following a successful socket connect. Thanks. From chris.hegarty at oracle.com Wed Oct 5 19:57:12 2011 From: chris.hegarty at oracle.com (chris hegarty) Date: Wed, 05 Oct 2011 20:57:12 +0100 Subject: code review request: 7094377 Com.sun.jndi.ldap.read.timeout doesn't work with ldaps. In-Reply-To: <4E8C619C.6020900@oracle.com> References: <4E8C619C.6020900@oracle.com> Message-ID: <4E8CB698.5030202@oracle.com> No that you were looking for my review, but looks fine to me. ;-) -Chris. On 05/10/2011 14:54, Vincent Ryan wrote: > Please review a fix for: > 7094377 Com.sun.jndi.ldap.read.timeout doesn't work with ldaps. > > The webrev is available at: > http://cr.openjdk.java.net/~vinnie/7094377/webrev.00/ > > To ensure that LDAP timeouts work correctly on an LDAP over SSL > connection, the LDAP connect timeout should include the SSL handshake > phase that takes place following a successful socket connect. > > Thanks. From chris.hegarty at oracle.com Thu Oct 6 13:24:28 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 06 Oct 2011 13:24:28 +0000 Subject: hg: jdk8/tl/jdk: 7090499: missing rawtypes warnings in anonymous inner class Message-ID: <20111006132450.30F6947C40@hg.openjdk.java.net> Changeset: ff5e57dc1fb3 Author: chegar Date: 2011-10-06 12:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff5e57dc1fb3 7090499: missing rawtypes warnings in anonymous inner class Summary: Fix anonymous inner classes with raw types currently being built in the jdk with -Werror Reviewed-by: mcimadamore, alanb ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java From maurizio.cimadamore at oracle.com Thu Oct 6 17:46:10 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 06 Oct 2011 17:46:10 +0000 Subject: hg: jdk8/tl/langtools: 7090499: missing rawtypes warnings in anonymous inner class Message-ID: <20111006174614.CE47A47C4A@hg.openjdk.java.net> Changeset: 47147081d5b4 Author: mcimadamore Date: 2011-10-06 18:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/47147081d5b4 7090499: missing rawtypes warnings in anonymous inner class Summary: javac does not detect raw types inside anonymous inner classes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/warnings/7090499/T7090499.java + test/tools/javac/warnings/7090499/T7090499.out From naoto.sato at oracle.com Fri Oct 7 02:45:19 2011 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 07 Oct 2011 02:45:19 +0000 Subject: hg: jdk8/tl/jdk: 7098394: JDK8 TL repo build fails in src/solaris/native/java/util/TimeZone_md.c Message-ID: <20111007024537.1905447C70@hg.openjdk.java.net> Changeset: b8a1d30d6c65 Author: naoto Date: 2011-10-06 17:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b8a1d30d6c65 7098394: JDK8 TL repo build fails in src/solaris/native/java/util/TimeZone_md.c Reviewed-by: chegar ! src/solaris/native/java/util/TimeZone_md.c From vincent.x.ryan at oracle.com Fri Oct 7 13:11:07 2011 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Fri, 07 Oct 2011 13:11:07 +0000 Subject: hg: jdk8/tl/jdk: 7094377: Com.sun.jndi.ldap.read.timeout doesn't work with ldaps. Message-ID: <20111007131128.B236947CAB@hg.openjdk.java.net> Changeset: 2edaef22de23 Author: vinnie Date: 2011-10-07 14:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2edaef22de23 7094377: Com.sun.jndi.ldap.read.timeout doesn't work with ldaps. Reviewed-by: chegar ! src/share/classes/com/sun/jndi/ldap/Connection.java + test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java From chris.hegarty at oracle.com Mon Oct 10 10:04:11 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 10 Oct 2011 10:04:11 +0000 Subject: hg: jdk8/tl/jdk: 7098719: -Dsun.net.maxDatagramSockets and Socket constructor does not work correctly with System.gc() Message-ID: <20111010100435.6866047E2C@hg.openjdk.java.net> Changeset: 1e89a13d9d8f Author: chegar Date: 2011-10-10 10:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1e89a13d9d8f 7098719: -Dsun.net.maxDatagramSockets and Socket constructor does not work correctly with System.gc() Reviewed-by: michaelm ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java From chris.hegarty at oracle.com Mon Oct 10 14:30:27 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 10 Oct 2011 14:30:27 +0000 Subject: hg: jdk8/tl/jdk: 7098755: test/sun/misc/JarIndex/metaInfFilenames/Basic.java should use supported compiler interface Message-ID: <20111010143049.3EF0047E51@hg.openjdk.java.net> Changeset: 2a36b8741363 Author: chegar Date: 2011-10-10 15:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a36b8741363 7098755: test/sun/misc/JarIndex/metaInfFilenames/Basic.java should use supported compiler interface Reviewed-by: mcimadamore ! test/sun/misc/JarIndex/metaInfFilenames/Basic.java From weijun.wang at oracle.com Tue Oct 11 01:05:29 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 10 Oct 2011 18:05:29 -0700 Subject: code review request: 7099399: cannot deal with CRL file larger than 16MB Message-ID: <4E939659.3020406@oracle.com> Webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.00/ Basically, we're now accepting X.509 block of 4-octets length. For simplicity, the highest byte must be <= 127, so that the length can be expressed with a 32-bit int. Thanks Max -------- Original Message -------- *Change Request ID*: 7099399 *Synopsis*: cannot deal with CRL file larger than 16MB Product: java Category: java Subcategory: classes_security Type: Defect === *Description* ============================================================ The X.509 impl of CertificateFactory only parses X.509 blocks smaller than 16MB, i.e. when the length can be encoded in 3 octets. Now we have a customer whose CRL file is as big as 30MB. From xuelei.fan at oracle.com Tue Oct 11 02:15:41 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 11 Oct 2011 10:15:41 +0800 Subject: code review request: 7099399: cannot deal with CRL file larger than 16MB In-Reply-To: <4E939659.3020406@oracle.com> References: <4E939659.3020406@oracle.com> Message-ID: <4E93A6CD.5050800@oracle.com> I'm not sure why the latest byte cannot be 0xFF? What about if my content length is 256? For example: 677 if (lowByte == -1) { 678 throw new IOException("Incomplete BER/DER length info"); 679 } Otherwise, looks fine to me. Xuelei On 10/11/2011 9:05 AM, Weijun Wang wrote: > Webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.00/ > > Basically, we're now accepting X.509 block of 4-octets length. For > simplicity, the highest byte must be <= 127, so that the length can be > expressed with a 32-bit int. > > Thanks > Max > > > -------- Original Message -------- > *Change Request ID*: 7099399 > *Synopsis*: cannot deal with CRL file larger than 16MB > > Product: java > Category: java > Subcategory: classes_security > Type: Defect > > === *Description* > ============================================================ > The X.509 impl of CertificateFactory only parses X.509 blocks smaller > than 16MB, i.e. when the length can be encoded in 3 octets. Now we have > a customer whose CRL file is as big as 30MB. > From weijun.wang at oracle.com Tue Oct 11 03:13:50 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 10 Oct 2011 20:13:50 -0700 Subject: code review request: 7099399: cannot deal with CRL file larger than 16MB In-Reply-To: <4E93A6CD.5050800@oracle.com> References: <4E939659.3020406@oracle.com> <4E93A6CD.5050800@oracle.com> Message-ID: 0xff will be 255, -1 means no byte to read, EOF. On Oct 10, 2011, at 7:15 PM, Xuelei Fan wrote: > I'm not sure why the latest byte cannot be 0xFF? What about if my > content length is 256? For example: > > 677 if (lowByte == -1) { > 678 throw new IOException("Incomplete BER/DER length info"); > 679 } > > Otherwise, looks fine to me. > > Xuelei > > On 10/11/2011 9:05 AM, Weijun Wang wrote: >> Webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.00/ >> >> Basically, we're now accepting X.509 block of 4-octets length. For >> simplicity, the highest byte must be <= 127, so that the length can be >> expressed with a 32-bit int. >> >> Thanks >> Max >> >> >> -------- Original Message -------- >> *Change Request ID*: 7099399 >> *Synopsis*: cannot deal with CRL file larger than 16MB >> >> Product: java >> Category: java >> Subcategory: classes_security >> Type: Defect >> >> === *Description* >> ============================================================ >> The X.509 impl of CertificateFactory only parses X.509 blocks smaller >> than 16MB, i.e. when the length can be encoded in 3 octets. Now we have >> a customer whose CRL file is as big as 30MB. >> > From xuelei.fan at oracle.com Tue Oct 11 03:19:15 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 11 Oct 2011 11:19:15 +0800 Subject: code review request: 7099399: cannot deal with CRL file larger than 16MB In-Reply-To: References: <4E939659.3020406@oracle.com> <4E93A6CD.5050800@oracle.com> Message-ID: <4E93B5B3.80507@oracle.com> Right! Then fine to me. Thanks, Xuelei On 10/11/2011 11:13 AM, Weijun Wang wrote: > 0xff will be 255, -1 means no byte to read, EOF. > > > On Oct 10, 2011, at 7:15 PM, Xuelei Fan wrote: > >> I'm not sure why the latest byte cannot be 0xFF? What about if my >> content length is 256? For example: >> >> 677 if (lowByte == -1) { >> 678 throw new IOException("Incomplete BER/DER length info"); >> 679 } >> >> Otherwise, looks fine to me. >> >> Xuelei >> >> On 10/11/2011 9:05 AM, Weijun Wang wrote: >>> Webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.00/ >>> >>> Basically, we're now accepting X.509 block of 4-octets length. For >>> simplicity, the highest byte must be <= 127, so that the length can be >>> expressed with a 32-bit int. >>> >>> Thanks >>> Max >>> >>> >>> -------- Original Message -------- >>> *Change Request ID*: 7099399 >>> *Synopsis*: cannot deal with CRL file larger than 16MB >>> >>> Product: java >>> Category: java >>> Subcategory: classes_security >>> Type: Defect >>> >>> === *Description* >>> ============================================================ >>> The X.509 impl of CertificateFactory only parses X.509 blocks smaller >>> than 16MB, i.e. when the length can be encoded in 3 octets. Now we have >>> a customer whose CRL file is as big as 30MB. >>> >> From weijun.wang at oracle.com Tue Oct 11 05:59:51 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 10 Oct 2011 22:59:51 -0700 Subject: code review request: 7099399: cannot deal with CRL file larger than 16MB In-Reply-To: <4E93B5B3.80507@oracle.com> References: <4E939659.3020406@oracle.com> <4E93A6CD.5050800@oracle.com> <4E93B5B3.80507@oracle.com> Message-ID: <4E93DB57.7060600@oracle.com> I'm now running JPRT tests on this fix. Unfortunately, for the 6 finished tests, I've already seen linux-i586 and solaris-i586 (both with c1 VM) failed on the new test with java.lang.OutOfMemoryError: Java heap space I guess our DER parsing codes are using too many memory. Maybe multiple copies of huge byte array here and there. In the short term, I'll see if I can rewrite the test with othervm and a proper -Xmx option. Hopefully customer dealing with these huge CRLs always use c2 VM with lots of memory. -Max On 10/10/2011 8:19 PM, Xuelei Fan wrote: > Right! Then fine to me. > > Thanks, > Xuelei > > On 10/11/2011 11:13 AM, Weijun Wang wrote: >> 0xff will be 255, -1 means no byte to read, EOF. >> >> >> On Oct 10, 2011, at 7:15 PM, Xuelei Fan wrote: >> >>> I'm not sure why the latest byte cannot be 0xFF? What about if my >>> content length is 256? For example: >>> >>> 677 if (lowByte == -1) { >>> 678 throw new IOException("Incomplete BER/DER length info"); >>> 679 } >>> >>> Otherwise, looks fine to me. >>> >>> Xuelei >>> >>> On 10/11/2011 9:05 AM, Weijun Wang wrote: >>>> Webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.00/ >>>> >>>> Basically, we're now accepting X.509 block of 4-octets length. For >>>> simplicity, the highest byte must be<= 127, so that the length can be >>>> expressed with a 32-bit int. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> -------- Original Message -------- >>>> *Change Request ID*: 7099399 >>>> *Synopsis*: cannot deal with CRL file larger than 16MB >>>> >>>> Product: java >>>> Category: java >>>> Subcategory: classes_security >>>> Type: Defect >>>> >>>> === *Description* >>>> ============================================================ >>>> The X.509 impl of CertificateFactory only parses X.509 blocks smaller >>>> than 16MB, i.e. when the length can be encoded in 3 octets. Now we have >>>> a customer whose CRL file is as big as 30MB. >>>> >>> > From vincent.x.ryan at oracle.com Tue Oct 11 12:40:26 2011 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 11 Oct 2011 13:40:26 +0100 Subject: 7054637 closed/lib/security/cacerts/VerifyCACerts.java failed on solaris 11 In-Reply-To: <201109240024.p8O0OciP013178@rcsinet13.oracle.com> References: <4E70EFA9.6020707@oracle.com> <201109222219.p8MMJ42d030120@rcsinet13.oracle.com> <4E7CA8B1.8020708@oracle.com> <201109231641.p8NGf8pB025305@acsinet11.oracle.com> <4E7CE84D.9080905@oracle.com> <201109240024.p8O0OciP013178@rcsinet13.oracle.com> Message-ID: <4E94393A.2010606@oracle.com> Hello Michael, I agree with your preference for symmetric handling of the EC point encoding/decoding. So I've modified the decoder method in P11Key.java to use the security provider config attribute 'useEcX963Encoding' just like the encoder method in P11ECKeyFactory.java The updated webrev is at: http://cr.openjdk.java.net/~vinnie/7099228/webrev.00/ (NOTE: I've used a new bug ID for this change) Thanks. On 09/24/11 01:24 AM, Michael StJohns wrote: > At 04:13 PM 9/23/2011, Vincent Ryan wrote: >> On 09/23/11 05:41 PM, Michael StJohns wrote: >>> Heh - I thought this looked familiar. >>> >>> Please take a look at my comments in bug 6763530, especially the fix for P11Key around line 1017. >>> >> >> I didn't see any comments from you in bug 6763530? > > The 29 November comments are from me. > > > > >>> Would it make sense to back out the fix that was put into P11Key to fix that bug in favor of a provider based solution (e.g. same boolean check)? >>> >> >> I think the flexibility to decode either format regardless of the setting of >> the new configuration attribute is a useful benefit. However I'm not convinced >> that the decoder will ever need to parse an encoding that was not generated by >> it. > > Yeah - I was thinking that having the encode/decode make sure they're doing the same thing was a good idea. But I think as written it will do the right thing, albeit slightly less efficiently. > > >>> Otherwise I'm fine with this fix. >>> >> >> Great. Thanks. >> >> >>> Mike >>> >>> >>> At 11:41 AM 9/23/2011, Vincent Ryan wrote: >>>> Thanks for your feedback Michael. I agree that your provider-based solution is >>>> preferable. Here's a revised webrev: >>>> >>>> http://cr.openjdk.java.net/~vinnie/7054637/webrev.01/ >>>> >>>> >>>> >>>> On 09/22/11 11:18 PM, Michael StJohns wrote: >>>>> Hi Vincent - >>>>> >>>>> Sorry - it took me a few days to look at this. I can't support it. >>>>> >>>>> I think this the wrong way to do things - specifically the dependence on the >>>>> presence of a PKCS11 attribute in the Vendor space. >>>>> >>>>> You've got a value in PKCS11Constants >>>>> >>>>> >>>>> + /* Only the raw encoding for an EC point is >>>>> supported */ >>>>> + public static final long CKA_ENABLE_RAW_EC_POINT = >>>>> (CKA_VENDOR_DEFINED | 1); >>>>> + >>>>> >>>>> >>>>> The problem is that this has a pretty good chance of colliding with an actual >>>>> vendor defined value. For example, Utimaco has CKA_ATTRIBUTE_LIST 0x80000001 >>>>> (same as CKA_VENDOR_DEFINED | 1). >>>>> >>>>> Instead, use the attribute list of the provider configuration. You'll have to >>>>> mod sun.security.pkcs11.Config.java - but you won't have the changes in either >>>>> PKCS11Constants or Functions that are currently there. >>>>> >>>>> >>>>> The problem should be provider wide and not need a per-token config item. >>>>> >>>>> So the config file gets instead: >>>>> >>>>> useEcX963Encoding=true around line 13 of the .cfg file. >>>>> >>>>> Config.java sets the boolean useEcX963Encoding. >>>>> >>>>> P11ECKeyFactory.java checks "token.config.useEcX963Encoding". >>>>> >>>>> Avoid the use of the term "raw" please - that got us into a number of problems >>>>> when revising PKCS11. It actually tends to mean just the concatenation of the X >>>>> and Y points without a format identifier which is not what you mean here >>>>> according to PKCS11. X9.63 encoding is 1 octet of format identifier - generally >>>>> 04 for uncompressed - and 2N bytes of X and Y. ECPoint (as defined in PKCS11) >>>>> is the X9.63 encoding wrapped in an ASN1 OctetString. >>>>> >>>>> >>>>> Thanks! Mike >>>>> >>>>> >>>>> At 02:17 PM 9/14/2011, Vincent Ryan wrote: >>>>>> Please review the following fix to the SunPKCS11 JCE provider: >>>>>> >>>>>> http://cr.openjdk.java.net/~vinnie/7054637/webrev.00/ >>>>>> >>>>>> The problem is that some older PKCS11 tokens support only the raw encoding for >>>>>> EC point in Elliptic Curve public keys. This fix introduces a configuration >>>>>> attribute that controls whether the raw-encoding or DER-encoding shall be used. >>>>>> >>>>>> It aids interoperability between older and newer PKCS11 tokens. >>>>>> >>>>>> Thanks. >>>>> >>> >>> > > From chris.hegarty at oracle.com Tue Oct 11 13:34:35 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 11 Oct 2011 13:34:35 +0000 Subject: hg: jdk8/tl/jdk: 7099488: TwoStacksPlainSocketImpl should invoke super.create(stream), typo in fix for 7098719 Message-ID: <20111011133453.E7ECA47F0C@hg.openjdk.java.net> Changeset: 5bfe2de1157b Author: chegar Date: 2011-10-11 12:06 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bfe2de1157b 7099488: TwoStacksPlainSocketImpl should invoke super.create(stream), typo in fix for 7098719 Reviewed-by: coffeys ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java From mstjohns at comcast.net Tue Oct 11 19:19:03 2011 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 11 Oct 2011 15:19:03 -0400 Subject: 7054637 closed/lib/security/cacerts/VerifyCACerts.java failed on solaris 11 In-Reply-To: <4E94393A.2010606@oracle.com> References: <4E70EFA9.6020707@oracle.com> <201109222219.p8MMJ42d030120@rcsinet13.oracle.com> <4E7CA8B1.8020708@oracle.com> <201109231641.p8NGf8pB025305@acsinet11.oracle.com> <4E7CE84D.9080905@oracle.com> <201109240024.p8O0OciP013178@rcsinet13.oracle.com> <4E94393A.2010606@oracle.com> Message-ID: <20111011191915.85D056F6D@mail.openjdk.java.net> Looks good to me. At 08:40 AM 10/11/2011, Vincent Ryan wrote: >Hello Michael, > >I agree with your preference for symmetric handling of the EC point >encoding/decoding. So I've modified the decoder method in P11Key.java >to use the security provider config attribute 'useEcX963Encoding' just >like the encoder method in P11ECKeyFactory.java > >The updated webrev is at: > http://cr.openjdk.java.net/~vinnie/7099228/webrev.00/ > >(NOTE: I've used a new bug ID for this change) > >Thanks. > > >On 09/24/11 01:24 AM, Michael StJohns wrote: >> At 04:13 PM 9/23/2011, Vincent Ryan wrote: >>> On 09/23/11 05:41 PM, Michael StJohns wrote: >>>> Heh - I thought this looked familiar. >>>> >>>> Please take a look at my comments in bug 6763530, especially the fix for P11Key around line 1017. >>>> >>> >>> I didn't see any comments from you in bug 6763530? >> >> The 29 November comments are from me. >> >> >> >> >>>> Would it make sense to back out the fix that was put into P11Key to fix that bug in favor of a provider based solution (e.g. same boolean check)? >>>> >>> >>> I think the flexibility to decode either format regardless of the setting of >>> the new configuration attribute is a useful benefit. However I'm not convinced >>> that the decoder will ever need to parse an encoding that was not generated by >>> it. >> >> Yeah - I was thinking that having the encode/decode make sure they're doing the same thing was a good idea. But I think as written it will do the right thing, albeit slightly less efficiently. >> >> >>>> Otherwise I'm fine with this fix. >>>> >>> >>> Great. Thanks. >>> >>> >>>> Mike >>>> >>>> >>>> At 11:41 AM 9/23/2011, Vincent Ryan wrote: >>>>> Thanks for your feedback Michael. I agree that your provider-based solution is >>>>> preferable. Here's a revised webrev: >>>>> >>>>> http://cr.openjdk.java.net/~vinnie/7054637/webrev.01/ >>>>> >>>>> >>>>> >>>>> On 09/22/11 11:18 PM, Michael StJohns wrote: >>>>>> Hi Vincent - >>>>>> >>>>>> Sorry - it took me a few days to look at this. I can't support it. >>>>>> >>>>>> I think this the wrong way to do things - specifically the dependence on the >>>>>> presence of a PKCS11 attribute in the Vendor space. >>>>>> >>>>>> You've got a value in PKCS11Constants >>>>>> >>>>>> >>>>>> + /* Only the raw encoding for an EC point is >>>>>> supported */ >>>>>> + public static final long CKA_ENABLE_RAW_EC_POINT = >>>>>> (CKA_VENDOR_DEFINED | 1); >>>>>> + >>>>>> >>>>>> >>>>>> The problem is that this has a pretty good chance of colliding with an actual >>>>>> vendor defined value. For example, Utimaco has CKA_ATTRIBUTE_LIST 0x80000001 >>>>>> (same as CKA_VENDOR_DEFINED | 1). >>>>>> >>>>>> Instead, use the attribute list of the provider configuration. You'll have to >>>>>> mod sun.security.pkcs11.Config.java - but you won't have the changes in either >>>>>> PKCS11Constants or Functions that are currently there. >>>>>> >>>>>> >>>>>> The problem should be provider wide and not need a per-token config item. >>>>>> >>>>>> So the config file gets instead: >>>>>> >>>>>> useEcX963Encoding=true around line 13 of the .cfg file. >>>>>> >>>>>> Config.java sets the boolean useEcX963Encoding. >>>>>> >>>>>> P11ECKeyFactory.java checks "token.config.useEcX963Encoding". >>>>>> >>>>>> Avoid the use of the term "raw" please - that got us into a number of problems >>>>>> when revising PKCS11. It actually tends to mean just the concatenation of the X >>>>>> and Y points without a format identifier which is not what you mean here >>>>>> according to PKCS11. X9.63 encoding is 1 octet of format identifier - generally >>>>>> 04 for uncompressed - and 2N bytes of X and Y. ECPoint (as defined in PKCS11) >>>>>> is the X9.63 encoding wrapped in an ASN1 OctetString. >>>>>> >>>>>> >>>>>> Thanks! Mike >>>>>> >>>>>> >>>>>> At 02:17 PM 9/14/2011, Vincent Ryan wrote: >>>>>>> Please review the following fix to the SunPKCS11 JCE provider: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~vinnie/7054637/webrev.00/ >>>>>>> >>>>>>> The problem is that some older PKCS11 tokens support only the raw encoding for >>>>>>> EC point in Elliptic Curve public keys. This fix introduces a configuration >>>>>>> attribute that controls whether the raw-encoding or DER-encoding shall be used. >>>>>>> >>>>>>> It aids interoperability between older and newer PKCS11 tokens. >>>>>>> >>>>>>> Thanks. >>>>>> >>>> >>>> >> >> From mstjohns at comcast.net Tue Oct 11 19:50:01 2011 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 11 Oct 2011 15:50:01 -0400 Subject: code review request: 7099399: cannot deal with CRL file larger than 16MB In-Reply-To: <4E939659.3020406@oracle.com> References: <4E939659.3020406@oracle.com> Message-ID: <20111011195006.25A676F77@mail.openjdk.java.net> Two things - 1) Why not just extend this to support "unsigned" long rather than just the 32 bit value - not saying it will be needed, but seems like you might as well do this once. 2) How about cleaning up this section of code and moving it to an iterative model: long length = 0; if (n < 0x80) length = n; else if (n == 0x80) { // indefinite encoding } else { int bytecount = (n &0x7f); int lencount = bytecount; // needed to do a write to bout int tempbyte; is.mark(8); if (bytecount > 8) error; // can't fit this in a long do { tempbyte = is.read(); if (tempbyte == -1) error - encoding EOL; if ((length & 0x7f) != 0 & bytecount == 8) error; // can't do an unsigned long length = (length << 8) | tempbyte; bytecount--; } while (bytecount > 0); is.reset(); for (int i = 0; i < lencount; i++) { bout.write(is.read()); } } At 09:05 PM 10/10/2011, Weijun Wang wrote: >Webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.00/ > >Basically, we're now accepting X.509 block of 4-octets length. For simplicity, the highest byte must be <= 127, so that the length can be expressed with a 32-bit int. > >Thanks >Max > > >-------- Original Message -------- >*Change Request ID*: 7099399 >*Synopsis*: cannot deal with CRL file larger than 16MB > > Product: java > Category: java > Subcategory: classes_security > Type: Defect > >=== *Description* ============================================================ >The X.509 impl of CertificateFactory only parses X.509 blocks smaller than 16MB, i.e. when the length can be encoded in 3 octets. Now we have a customer whose CRL file is as big as 30MB. From weijun.wang at oracle.com Tue Oct 11 20:06:51 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 11 Oct 2011 13:06:51 -0700 Subject: code review request: 7099399: cannot deal with CRL file larger than 16MB In-Reply-To: <201110111950.p9BJo71D011025@acsinet11.oracle.com> References: <4E939659.3020406@oracle.com> <201110111950.p9BJo71D011025@acsinet11.oracle.com> Message-ID: <4E94A1DB.6070905@oracle.com> On 10/11/2011 12:50 PM, Michael StJohns wrote: > Two things - > > 1) Why not just extend this to support "unsigned" long rather than just the 32 bit value - not saying it will be needed, but seems like you might as well do this once. Well, InputStream::read only supports 32-bit int, and array length is also 32-bit int. Trying to read so many bytes will be quite complicated. > > 2) How about cleaning up this section of code and moving it to an iterative model: Yes, your codes look more correct. However, this is a regression bug and we need to fix it fast and with zero risk. Therefore, I choose this stupid and lazy code change. Thanks Max > > long length = 0; > > if (n< 0x80) > length = n; > else if (n == 0x80) { > // indefinite encoding > } else { > int bytecount = (n&0x7f); > int lencount = bytecount; // needed to do a write to bout > int tempbyte; > is.mark(8); > if (bytecount> 8) > error; // can't fit this in a long > > do { > tempbyte = is.read(); > if (tempbyte == -1) > error - encoding EOL; > if ((length& 0x7f) != 0& bytecount == 8) > error; // can't do an unsigned long > > length = (length<< 8) | tempbyte; > bytecount--; > } while (bytecount> 0); > > is.reset(); > for (int i = 0; i< lencount; i++) { > bout.write(is.read()); > } > > } > > > At 09:05 PM 10/10/2011, Weijun Wang wrote: >> Webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.00/ >> >> Basically, we're now accepting X.509 block of 4-octets length. For simplicity, the highest byte must be<= 127, so that the length can be expressed with a 32-bit int. >> >> Thanks >> Max >> >> >> -------- Original Message -------- >> *Change Request ID*: 7099399 >> *Synopsis*: cannot deal with CRL file larger than 16MB >> >> Product: java >> Category: java >> Subcategory: classes_security >> Type: Defect >> >> === *Description* ============================================================ >> The X.509 impl of CertificateFactory only parses X.509 blocks smaller than 16MB, i.e. when the length can be encoded in 3 octets. Now we have a customer whose CRL file is as big as 30MB. > > From mstjohns at comcast.net Tue Oct 11 20:16:44 2011 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 11 Oct 2011 16:16:44 -0400 Subject: code review request: 7099399: cannot deal with CRL file larger than 16MB In-Reply-To: <4E94A1DB.6070905@oracle.com> References: <4E939659.3020406@oracle.com> <201110111950.p9BJo71D011025@acsinet11.oracle.com> <4E94A1DB.6070905@oracle.com> Message-ID: <20111011201710.C89806F84@mail.openjdk.java.net> At 04:06 PM 10/11/2011, Weijun Wang wrote: >>2) How about cleaning up this section of code and moving it to an iterative model: > >Yes, your codes look more correct. However, this is a regression bug and we need to fix it fast and with zero risk. Therefore, I choose this stupid and lazy code change. *laugh* Fair enough. From weijun.wang at oracle.com Tue Oct 11 23:32:26 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 11 Oct 2011 16:32:26 -0700 Subject: updated code review request: 7099399: cannot deal with CRL file larger than 16MB In-Reply-To: <4E93DB57.7060600@oracle.com> References: <4E939659.3020406@oracle.com> <4E93A6CD.5050800@oracle.com> <4E93B5B3.80507@oracle.com> <4E93DB57.7060600@oracle.com> Message-ID: <4E94D20A.9030608@oracle.com> Hi All I've updated the webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.01/ I would like at least 2 reviewers. It might need to go to 7u2. The src file is identical to the last version, and I made several changes to the test: 1. Now run in othervm. Though hasn't made any changes to the VM, the huge memory footprint might prevent other tests to be running smoothly, at least before a full gc. 2. It only runs on "Server" VMs now. My last JPRT test shows it failing on all c1 VMs and succeeding on all c2 VMs. I just finished a new JPRT test, all builds and tests pass on supported platforms. Thanks Max On 10/10/2011 10:59 PM, Weijun Wang wrote: > I'm now running JPRT tests on this fix. > > Unfortunately, for the 6 finished tests, I've already seen linux-i586 > and solaris-i586 (both with c1 VM) failed on the new test with > > java.lang.OutOfMemoryError: Java heap space > > I guess our DER parsing codes are using too many memory. Maybe multiple > copies of huge byte array here and there. In the short term, I'll see if > I can rewrite the test with othervm and a proper -Xmx option. > > Hopefully customer dealing with these huge CRLs always use c2 VM with > lots of memory. > > -Max > > On 10/10/2011 8:19 PM, Xuelei Fan wrote: >> Right! Then fine to me. >> >> Thanks, >> Xuelei >> >> On 10/11/2011 11:13 AM, Weijun Wang wrote: >>> 0xff will be 255, -1 means no byte to read, EOF. >>> >>> >>> On Oct 10, 2011, at 7:15 PM, Xuelei Fan wrote: >>> >>>> I'm not sure why the latest byte cannot be 0xFF? What about if my >>>> content length is 256? For example: >>>> >>>> 677 if (lowByte == -1) { >>>> 678 throw new IOException("Incomplete BER/DER length info"); >>>> 679 } >>>> >>>> Otherwise, looks fine to me. >>>> >>>> Xuelei >>>> >>>> On 10/11/2011 9:05 AM, Weijun Wang wrote: >>>>> Webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.00/ >>>>> >>>>> Basically, we're now accepting X.509 block of 4-octets length. For >>>>> simplicity, the highest byte must be<= 127, so that the length can be >>>>> expressed with a 32-bit int. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>> -------- Original Message -------- >>>>> *Change Request ID*: 7099399 >>>>> *Synopsis*: cannot deal with CRL file larger than 16MB >>>>> >>>>> Product: java >>>>> Category: java >>>>> Subcategory: classes_security >>>>> Type: Defect >>>>> >>>>> === *Description* >>>>> ============================================================ >>>>> The X.509 impl of CertificateFactory only parses X.509 blocks smaller >>>>> than 16MB, i.e. when the length can be encoded in 3 octets. Now we >>>>> have >>>>> a customer whose CRL file is as big as 30MB. >>>>> >>>> >> From xuelei.fan at oracle.com Wed Oct 12 02:29:17 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 12 Oct 2011 10:29:17 +0800 Subject: updated code review request: 7099399: cannot deal with CRL file larger than 16MB In-Reply-To: <4E94D20A.9030608@oracle.com> References: <4E939659.3020406@oracle.com> <4E93A6CD.5050800@oracle.com> <4E93B5B3.80507@oracle.com> <4E93DB57.7060600@oracle.com> <4E94D20A.9030608@oracle.com> Message-ID: <4E94FB7D.1060301@oracle.com> Fine to me. Xuelei On 10/12/2011 7:32 AM, Weijun Wang wrote: > Hi All > > I've updated the webrev at > > http://cr.openjdk.java.net/~weijun/7099399/webrev.01/ > > I would like at least 2 reviewers. It might need to go to 7u2. > > The src file is identical to the last version, and I made several > changes to the test: > > 1. Now run in othervm. Though hasn't made any changes to the VM, the > huge memory footprint might prevent other tests to be running smoothly, > at least before a full gc. > > 2. It only runs on "Server" VMs now. My last JPRT test shows it failing > on all c1 VMs and succeeding on all c2 VMs. > > I just finished a new JPRT test, all builds and tests pass on supported > platforms. > > Thanks > Max > > > On 10/10/2011 10:59 PM, Weijun Wang wrote: >> I'm now running JPRT tests on this fix. >> >> Unfortunately, for the 6 finished tests, I've already seen linux-i586 >> and solaris-i586 (both with c1 VM) failed on the new test with >> >> java.lang.OutOfMemoryError: Java heap space >> >> I guess our DER parsing codes are using too many memory. Maybe multiple >> copies of huge byte array here and there. In the short term, I'll see if >> I can rewrite the test with othervm and a proper -Xmx option. >> >> Hopefully customer dealing with these huge CRLs always use c2 VM with >> lots of memory. >> >> -Max >> >> On 10/10/2011 8:19 PM, Xuelei Fan wrote: >>> Right! Then fine to me. >>> >>> Thanks, >>> Xuelei >>> >>> On 10/11/2011 11:13 AM, Weijun Wang wrote: >>>> 0xff will be 255, -1 means no byte to read, EOF. >>>> >>>> >>>> On Oct 10, 2011, at 7:15 PM, Xuelei Fan wrote: >>>> >>>>> I'm not sure why the latest byte cannot be 0xFF? What about if my >>>>> content length is 256? For example: >>>>> >>>>> 677 if (lowByte == -1) { >>>>> 678 throw new IOException("Incomplete BER/DER length info"); >>>>> 679 } >>>>> >>>>> Otherwise, looks fine to me. >>>>> >>>>> Xuelei >>>>> >>>>> On 10/11/2011 9:05 AM, Weijun Wang wrote: >>>>>> Webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.00/ >>>>>> >>>>>> Basically, we're now accepting X.509 block of 4-octets length. For >>>>>> simplicity, the highest byte must be<= 127, so that the length can be >>>>>> expressed with a 32-bit int. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>> -------- Original Message -------- >>>>>> *Change Request ID*: 7099399 >>>>>> *Synopsis*: cannot deal with CRL file larger than 16MB >>>>>> >>>>>> Product: java >>>>>> Category: java >>>>>> Subcategory: classes_security >>>>>> Type: Defect >>>>>> >>>>>> === *Description* >>>>>> ============================================================ >>>>>> The X.509 impl of CertificateFactory only parses X.509 blocks smaller >>>>>> than 16MB, i.e. when the length can be encoded in 3 octets. Now we >>>>>> have >>>>>> a customer whose CRL file is as big as 30MB. >>>>>> >>>>> >>> From neil.richards at ngmr.net Mon Oct 10 15:21:32 2011 From: neil.richards at ngmr.net (neil.richards at ngmr.net) Date: Mon, 10 Oct 2011 15:21:32 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20111010152152.97C3B47E5A@hg.openjdk.java.net> Changeset: dd55467dd1f2 Author: ngmr Date: 2011-10-10 14:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd55467dd1f2 7099119: Remove unused dlinfo local variable in launcher code Reviewed-by: ohair, chegar, ngmr Contributed-by: Steve Poole ! src/solaris/bin/java_md.c Changeset: 5f336e0d4d97 Author: ngmr Date: 2011-10-10 16:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f336e0d4d97 Merge From xuelei.fan at oracle.com Wed Oct 12 09:11:48 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 12 Oct 2011 09:11:48 +0000 Subject: hg: jdk8/tl/jdk: 7092375: Security Libraries don't build with javac -Werror Message-ID: <20111012091207.D105347F6C@hg.openjdk.java.net> Changeset: ffa762153af4 Author: xuelei Date: 2011-09-28 15:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ffa762153af4 7092375: Security Libraries don't build with javac -Werror Summary: Changes to security related java and make files to remove warnings Reviewed-by: xuelei Contributed-by: kurchi.subhra.hazra at oracle.com ! make/java/security/Makefile ! make/javax/Makefile ! make/javax/others/Makefile + make/javax/security/Makefile ! make/org/ietf/jgss/Makefile ! make/sun/security/other/Makefile ! src/share/classes/java/security/Signature.java ! src/share/classes/javax/security/auth/PrivateCredentialPermission.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/security/auth/SubjectDomainCombiner.java ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/javax/security/auth/login/LoginContext.java ! src/share/classes/javax/security/auth/x500/X500Principal.java ! src/share/classes/javax/security/cert/CertificateEncodingException.java ! src/share/classes/javax/security/cert/CertificateException.java ! src/share/classes/javax/security/cert/CertificateExpiredException.java ! src/share/classes/javax/security/cert/CertificateNotYetValidException.java ! src/share/classes/javax/security/cert/CertificateParsingException.java ! src/share/classes/javax/security/cert/X509Certificate.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/smartcardio/TerminalFactory.java ! src/share/classes/sun/security/ec/ECPublicKeyImpl.java ! src/share/classes/sun/security/validator/PKIXValidator.java ! src/share/classes/sun/security/validator/SimpleValidator.java ! src/share/classes/sun/security/x509/X509CertImpl.java From sean.mullan at oracle.com Wed Oct 12 14:19:05 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 12 Oct 2011 10:19:05 -0400 Subject: updated code review request: 7099399: cannot deal with CRL file larger than 16MB In-Reply-To: <4E94D20A.9030608@oracle.com> References: <4E939659.3020406@oracle.com> <4E93A6CD.5050800@oracle.com> <4E93B5B3.80507@oracle.com> <4E93DB57.7060600@oracle.com> <4E94D20A.9030608@oracle.com> Message-ID: <4E95A1D9.8010605@oracle.com> On 10/11/11 7:32 PM, Weijun Wang wrote: > Hi All > > I've updated the webrev at > > http://cr.openjdk.java.net/~weijun/7099399/webrev.01/ > > I would like at least 2 reviewers. It might need to go to 7u2. > > The src file is identical to the last version, and I made several > changes to the test: > > 1. Now run in othervm. Though hasn't made any changes to the VM, the > huge memory footprint might prevent other tests to be running smoothly, > at least before a full gc. > > 2. It only runs on "Server" VMs now. My last JPRT test shows it failing > on all c1 VMs and succeeding on all c2 VMs. Is that the only way to determine if a server VM is being used? The name and whether it includes "Server" seems to be implementation specific. Otherwise looks fine to me. --Sean > > I just finished a new JPRT test, all builds and tests pass on supported > platforms. > > Thanks > Max > > > On 10/10/2011 10:59 PM, Weijun Wang wrote: >> I'm now running JPRT tests on this fix. >> >> Unfortunately, for the 6 finished tests, I've already seen linux-i586 >> and solaris-i586 (both with c1 VM) failed on the new test with >> >> java.lang.OutOfMemoryError: Java heap space >> >> I guess our DER parsing codes are using too many memory. Maybe multiple >> copies of huge byte array here and there. In the short term, I'll see if >> I can rewrite the test with othervm and a proper -Xmx option. >> >> Hopefully customer dealing with these huge CRLs always use c2 VM with >> lots of memory. >> >> -Max >> >> On 10/10/2011 8:19 PM, Xuelei Fan wrote: >>> Right! Then fine to me. >>> >>> Thanks, >>> Xuelei >>> >>> On 10/11/2011 11:13 AM, Weijun Wang wrote: >>>> 0xff will be 255, -1 means no byte to read, EOF. >>>> >>>> >>>> On Oct 10, 2011, at 7:15 PM, Xuelei Fan wrote: >>>> >>>>> I'm not sure why the latest byte cannot be 0xFF? What about if my >>>>> content length is 256? For example: >>>>> >>>>> 677 if (lowByte == -1) { >>>>> 678 throw new IOException("Incomplete BER/DER length info"); >>>>> 679 } >>>>> >>>>> Otherwise, looks fine to me. >>>>> >>>>> Xuelei >>>>> >>>>> On 10/11/2011 9:05 AM, Weijun Wang wrote: >>>>>> Webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.00/ >>>>>> >>>>>> Basically, we're now accepting X.509 block of 4-octets length. For >>>>>> simplicity, the highest byte must be<= 127, so that the length can be >>>>>> expressed with a 32-bit int. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>> -------- Original Message -------- >>>>>> *Change Request ID*: 7099399 >>>>>> *Synopsis*: cannot deal with CRL file larger than 16MB >>>>>> >>>>>> Product: java >>>>>> Category: java >>>>>> Subcategory: classes_security >>>>>> Type: Defect >>>>>> >>>>>> === *Description* >>>>>> ============================================================ >>>>>> The X.509 impl of CertificateFactory only parses X.509 blocks smaller >>>>>> than 16MB, i.e. when the length can be encoded in 3 octets. Now we >>>>>> have >>>>>> a customer whose CRL file is as big as 30MB. >>>>>> >>>>> >>> From weijun.wang at oracle.com Wed Oct 12 15:08:25 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 12 Oct 2011 08:08:25 -0700 Subject: updated code review request: 7099399: cannot deal with CRL file larger than 16MB In-Reply-To: <4E95A1D9.8010605@oracle.com> References: <4E939659.3020406@oracle.com> <4E93A6CD.5050800@oracle.com> <4E93B5B3.80507@oracle.com> <4E93DB57.7060600@oracle.com> <4E94D20A.9030608@oracle.com> <4E95A1D9.8010605@oracle.com> Message-ID: On Oct 12, 2011, at 7:19 AM, Sean Mullan wrote: > On 10/11/11 7:32 PM, Weijun Wang wrote: >> Hi All >> >> I've updated the webrev at >> >> http://cr.openjdk.java.net/~weijun/7099399/webrev.01/ >> >> I would like at least 2 reviewers. It might need to go to 7u2. >> >> The src file is identical to the last version, and I made several >> changes to the test: >> >> 1. Now run in othervm. Though hasn't made any changes to the VM, the >> huge memory footprint might prevent other tests to be running smoothly, >> at least before a full gc. >> >> 2. It only runs on "Server" VMs now. My last JPRT test shows it failing >> on all c1 VMs and succeeding on all c2 VMs. > > Is that the only way to determine if a server VM is being used? The name and > whether it includes "Server" seems to be implementation specific. Yes it does not look reliable. In fact, this requirement of a server VM is only related to the max heap size. I'm about to do some measurement today. Hopefully I can add -Xmx??m in the @run line and remove the server VM check. That will need another webrev. -Max > > Otherwise looks fine to me. > > --Sean > >> >> I just finished a new JPRT test, all builds and tests pass on supported >> platforms. >> >> Thanks >> Max >> >> >> On 10/10/2011 10:59 PM, Weijun Wang wrote: >>> I'm now running JPRT tests on this fix. >>> >>> Unfortunately, for the 6 finished tests, I've already seen linux-i586 >>> and solaris-i586 (both with c1 VM) failed on the new test with >>> >>> java.lang.OutOfMemoryError: Java heap space >>> >>> I guess our DER parsing codes are using too many memory. Maybe multiple >>> copies of huge byte array here and there. In the short term, I'll see if >>> I can rewrite the test with othervm and a proper -Xmx option. >>> >>> Hopefully customer dealing with these huge CRLs always use c2 VM with >>> lots of memory. >>> >>> -Max >>> >>> On 10/10/2011 8:19 PM, Xuelei Fan wrote: >>>> Right! Then fine to me. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 10/11/2011 11:13 AM, Weijun Wang wrote: >>>>> 0xff will be 255, -1 means no byte to read, EOF. >>>>> >>>>> >>>>> On Oct 10, 2011, at 7:15 PM, Xuelei Fan wrote: >>>>> >>>>>> I'm not sure why the latest byte cannot be 0xFF? What about if my >>>>>> content length is 256? For example: >>>>>> >>>>>> 677 if (lowByte == -1) { >>>>>> 678 throw new IOException("Incomplete BER/DER length info"); >>>>>> 679 } >>>>>> >>>>>> Otherwise, looks fine to me. >>>>>> >>>>>> Xuelei >>>>>> >>>>>> On 10/11/2011 9:05 AM, Weijun Wang wrote: >>>>>>> Webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.00/ >>>>>>> >>>>>>> Basically, we're now accepting X.509 block of 4-octets length. For >>>>>>> simplicity, the highest byte must be<= 127, so that the length can be >>>>>>> expressed with a 32-bit int. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> >>>>>>> -------- Original Message -------- >>>>>>> *Change Request ID*: 7099399 >>>>>>> *Synopsis*: cannot deal with CRL file larger than 16MB >>>>>>> >>>>>>> Product: java >>>>>>> Category: java >>>>>>> Subcategory: classes_security >>>>>>> Type: Defect >>>>>>> >>>>>>> === *Description* >>>>>>> ============================================================ >>>>>>> The X.509 impl of CertificateFactory only parses X.509 blocks smaller >>>>>>> than 16MB, i.e. when the length can be encoded in 3 octets. Now we >>>>>>> have >>>>>>> a customer whose CRL file is as big as 30MB. >>>>>>> >>>>>> >>>> From weijun.wang at oracle.com Wed Oct 12 19:12:14 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 12 Oct 2011 12:12:14 -0700 Subject: updated code review request: 7099399: cannot deal with CRL file larger than 16MB In-Reply-To: <4E95A1D9.8010605@oracle.com> References: <4E939659.3020406@oracle.com> <4E93A6CD.5050800@oracle.com> <4E93B5B3.80507@oracle.com> <4E93DB57.7060600@oracle.com> <4E94D20A.9030608@oracle.com> <4E95A1D9.8010605@oracle.com> Message-ID: <4E95E68E.7090206@oracle.com> Sorry, a new updated webrev http://cr.openjdk.java.net/~weijun/7099399/webrev.02/ Still, no change for the src file. The test now does not check the VM version anymore. Instead, it sets max heap size to 1024MB. I've tried some experiments on various systems. 250MB is OK for all client VMs, but even 512MB is not enough on a windows server VM. Therefore I choose 1024MB, it also makes the test runs faster. Also, David Holmes warned that a VM might report "Tiered" rather than "Server". The test passes on all JPRT platforms. Linux is fast (~1m), solaris-sparc slower (~4m), and windows slowest (~5m). I'll look at the memory usage (that is, 6670894) next week. Thanks Max On 10/12/2011 7:19 AM, Sean Mullan wrote: > On 10/11/11 7:32 PM, Weijun Wang wrote: >> Hi All >> >> I've updated the webrev at >> >> http://cr.openjdk.java.net/~weijun/7099399/webrev.01/ >> >> I would like at least 2 reviewers. It might need to go to 7u2. >> >> The src file is identical to the last version, and I made several >> changes to the test: >> >> 1. Now run in othervm. Though hasn't made any changes to the VM, the >> huge memory footprint might prevent other tests to be running smoothly, >> at least before a full gc. >> >> 2. It only runs on "Server" VMs now. My last JPRT test shows it failing >> on all c1 VMs and succeeding on all c2 VMs. > > Is that the only way to determine if a server VM is being used? The name and > whether it includes "Server" seems to be implementation specific. > > Otherwise looks fine to me. > > --Sean > >> >> I just finished a new JPRT test, all builds and tests pass on supported >> platforms. >> >> Thanks >> Max >> >> >> On 10/10/2011 10:59 PM, Weijun Wang wrote: >>> I'm now running JPRT tests on this fix. >>> >>> Unfortunately, for the 6 finished tests, I've already seen linux-i586 >>> and solaris-i586 (both with c1 VM) failed on the new test with >>> >>> java.lang.OutOfMemoryError: Java heap space >>> >>> I guess our DER parsing codes are using too many memory. Maybe multiple >>> copies of huge byte array here and there. In the short term, I'll see if >>> I can rewrite the test with othervm and a proper -Xmx option. >>> >>> Hopefully customer dealing with these huge CRLs always use c2 VM with >>> lots of memory. >>> >>> -Max >>> >>> On 10/10/2011 8:19 PM, Xuelei Fan wrote: >>>> Right! Then fine to me. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 10/11/2011 11:13 AM, Weijun Wang wrote: >>>>> 0xff will be 255, -1 means no byte to read, EOF. >>>>> >>>>> >>>>> On Oct 10, 2011, at 7:15 PM, Xuelei Fan wrote: >>>>> >>>>>> I'm not sure why the latest byte cannot be 0xFF? What about if my >>>>>> content length is 256? For example: >>>>>> >>>>>> 677 if (lowByte == -1) { >>>>>> 678 throw new IOException("Incomplete BER/DER length info"); >>>>>> 679 } >>>>>> >>>>>> Otherwise, looks fine to me. >>>>>> >>>>>> Xuelei >>>>>> >>>>>> On 10/11/2011 9:05 AM, Weijun Wang wrote: >>>>>>> Webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.00/ >>>>>>> >>>>>>> Basically, we're now accepting X.509 block of 4-octets length. For >>>>>>> simplicity, the highest byte must be<= 127, so that the length can be >>>>>>> expressed with a 32-bit int. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> >>>>>>> -------- Original Message -------- >>>>>>> *Change Request ID*: 7099399 >>>>>>> *Synopsis*: cannot deal with CRL file larger than 16MB >>>>>>> >>>>>>> Product: java >>>>>>> Category: java >>>>>>> Subcategory: classes_security >>>>>>> Type: Defect >>>>>>> >>>>>>> === *Description* >>>>>>> ============================================================ >>>>>>> The X.509 impl of CertificateFactory only parses X.509 blocks smaller >>>>>>> than 16MB, i.e. when the length can be encoded in 3 octets. Now we >>>>>>> have >>>>>>> a customer whose CRL file is as big as 30MB. >>>>>>> >>>>>> >>>> From naoto.sato at oracle.com Wed Oct 12 19:13:38 2011 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 12 Oct 2011 19:13:38 +0000 Subject: hg: jdk8/tl/jdk: 7027061: Testcase failure: java/util/Locale/Bug6989440.java - java.util.ConcurrentModificationException Message-ID: <20111012191400.22A9A47FAA@hg.openjdk.java.net> Changeset: 829c3a8d23fa Author: naoto Date: 2011-10-12 12:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/829c3a8d23fa 7027061: Testcase failure: java/util/Locale/Bug6989440.java - java.util.ConcurrentModificationException Reviewed-by: dholmes, chegar ! src/share/classes/sun/util/LocaleServiceProviderPool.java ! test/java/util/Locale/Bug6989440.java From xuelei.fan at oracle.com Thu Oct 13 01:52:57 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 13 Oct 2011 09:52:57 +0800 Subject: updated code review request: 7099399: cannot deal with CRL file larger than 16MB In-Reply-To: <4E95E68E.7090206@oracle.com> References: <4E939659.3020406@oracle.com> <4E93A6CD.5050800@oracle.com> <4E93B5B3.80507@oracle.com> <4E93DB57.7060600@oracle.com> <4E94D20A.9030608@oracle.com> <4E95A1D9.8010605@oracle.com> <4E95E68E.7090206@oracle.com> Message-ID: <4E964479.3010703@oracle.com> Looks fine to me. Xuelei On 10/13/2011 3:12 AM, Weijun Wang wrote: > Sorry, a new updated webrev > > http://cr.openjdk.java.net/~weijun/7099399/webrev.02/ > > Still, no change for the src file. The test now does not check the VM > version anymore. Instead, it sets max heap size to 1024MB. I've tried > some experiments on various systems. 250MB is OK for all client VMs, but > even 512MB is not enough on a windows server VM. Therefore I choose > 1024MB, it also makes the test runs faster. > > Also, David Holmes warned that a VM might report "Tiered" rather than > "Server". > > The test passes on all JPRT platforms. Linux is fast (~1m), > solaris-sparc slower (~4m), and windows slowest (~5m). > > I'll look at the memory usage (that is, 6670894) next week. > > Thanks > Max > > On 10/12/2011 7:19 AM, Sean Mullan wrote: >> On 10/11/11 7:32 PM, Weijun Wang wrote: >>> Hi All >>> >>> I've updated the webrev at >>> >>> http://cr.openjdk.java.net/~weijun/7099399/webrev.01/ >>> >>> I would like at least 2 reviewers. It might need to go to 7u2. >>> >>> The src file is identical to the last version, and I made several >>> changes to the test: >>> >>> 1. Now run in othervm. Though hasn't made any changes to the VM, the >>> huge memory footprint might prevent other tests to be running smoothly, >>> at least before a full gc. >>> >>> 2. It only runs on "Server" VMs now. My last JPRT test shows it failing >>> on all c1 VMs and succeeding on all c2 VMs. >> >> Is that the only way to determine if a server VM is being used? The >> name and >> whether it includes "Server" seems to be implementation specific. >> >> Otherwise looks fine to me. >> >> --Sean >> >>> >>> I just finished a new JPRT test, all builds and tests pass on supported >>> platforms. >>> >>> Thanks >>> Max >>> >>> >>> On 10/10/2011 10:59 PM, Weijun Wang wrote: >>>> I'm now running JPRT tests on this fix. >>>> >>>> Unfortunately, for the 6 finished tests, I've already seen linux-i586 >>>> and solaris-i586 (both with c1 VM) failed on the new test with >>>> >>>> java.lang.OutOfMemoryError: Java heap space >>>> >>>> I guess our DER parsing codes are using too many memory. Maybe multiple >>>> copies of huge byte array here and there. In the short term, I'll >>>> see if >>>> I can rewrite the test with othervm and a proper -Xmx option. >>>> >>>> Hopefully customer dealing with these huge CRLs always use c2 VM with >>>> lots of memory. >>>> >>>> -Max >>>> >>>> On 10/10/2011 8:19 PM, Xuelei Fan wrote: >>>>> Right! Then fine to me. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 10/11/2011 11:13 AM, Weijun Wang wrote: >>>>>> 0xff will be 255, -1 means no byte to read, EOF. >>>>>> >>>>>> >>>>>> On Oct 10, 2011, at 7:15 PM, Xuelei Fan >>>>>> wrote: >>>>>> >>>>>>> I'm not sure why the latest byte cannot be 0xFF? What about if my >>>>>>> content length is 256? For example: >>>>>>> >>>>>>> 677 if (lowByte == -1) { >>>>>>> 678 throw new IOException("Incomplete BER/DER length info"); >>>>>>> 679 } >>>>>>> >>>>>>> Otherwise, looks fine to me. >>>>>>> >>>>>>> Xuelei >>>>>>> >>>>>>> On 10/11/2011 9:05 AM, Weijun Wang wrote: >>>>>>>> Webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.00/ >>>>>>>> >>>>>>>> Basically, we're now accepting X.509 block of 4-octets length. For >>>>>>>> simplicity, the highest byte must be<= 127, so that the length >>>>>>>> can be >>>>>>>> expressed with a 32-bit int. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>> >>>>>>>> -------- Original Message -------- >>>>>>>> *Change Request ID*: 7099399 >>>>>>>> *Synopsis*: cannot deal with CRL file larger than 16MB >>>>>>>> >>>>>>>> Product: java >>>>>>>> Category: java >>>>>>>> Subcategory: classes_security >>>>>>>> Type: Defect >>>>>>>> >>>>>>>> === *Description* >>>>>>>> ============================================================ >>>>>>>> The X.509 impl of CertificateFactory only parses X.509 blocks >>>>>>>> smaller >>>>>>>> than 16MB, i.e. when the length can be encoded in 3 octets. Now we >>>>>>>> have >>>>>>>> a customer whose CRL file is as big as 30MB. >>>>>>>> >>>>>>> >>>>> From sean.coffey at oracle.com Thu Oct 13 08:55:45 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 13 Oct 2011 09:55:45 +0100 Subject: updated code review request: 7099399: cannot deal with CRL file larger than 16MB In-Reply-To: <4E964479.3010703@oracle.com> References: <4E939659.3020406@oracle.com> <4E93A6CD.5050800@oracle.com> <4E93B5B3.80507@oracle.com> <4E93DB57.7060600@oracle.com> <4E94D20A.9030608@oracle.com> <4E95A1D9.8010605@oracle.com> <4E95E68E.7090206@oracle.com> <4E964479.3010703@oracle.com> Message-ID: <4E96A791.70906@oracle.com> Should this test be set to run manually ? 5 mins is far too long for a jtreg unit test IMO. regards, Sean. On 13/10/2011 02:52, Xuelei Fan wrote: > Looks fine to me. > > Xuelei > > On 10/13/2011 3:12 AM, Weijun Wang wrote: >> Sorry, a new updated webrev >> >> http://cr.openjdk.java.net/~weijun/7099399/webrev.02/ >> >> Still, no change for the src file. The test now does not check the VM >> version anymore. Instead, it sets max heap size to 1024MB. I've tried >> some experiments on various systems. 250MB is OK for all client VMs, but >> even 512MB is not enough on a windows server VM. Therefore I choose >> 1024MB, it also makes the test runs faster. >> >> Also, David Holmes warned that a VM might report "Tiered" rather than >> "Server". >> >> The test passes on all JPRT platforms. Linux is fast (~1m), >> solaris-sparc slower (~4m), and windows slowest (~5m). >> >> I'll look at the memory usage (that is, 6670894) next week. >> >> Thanks >> Max >> >> On 10/12/2011 7:19 AM, Sean Mullan wrote: >>> On 10/11/11 7:32 PM, Weijun Wang wrote: >>>> Hi All >>>> >>>> I've updated the webrev at >>>> >>>> http://cr.openjdk.java.net/~weijun/7099399/webrev.01/ >>>> >>>> I would like at least 2 reviewers. It might need to go to 7u2. >>>> >>>> The src file is identical to the last version, and I made several >>>> changes to the test: >>>> >>>> 1. Now run in othervm. Though hasn't made any changes to the VM, the >>>> huge memory footprint might prevent other tests to be running smoothly, >>>> at least before a full gc. >>>> >>>> 2. It only runs on "Server" VMs now. My last JPRT test shows it failing >>>> on all c1 VMs and succeeding on all c2 VMs. >>> Is that the only way to determine if a server VM is being used? The >>> name and >>> whether it includes "Server" seems to be implementation specific. >>> >>> Otherwise looks fine to me. >>> >>> --Sean >>> >>>> I just finished a new JPRT test, all builds and tests pass on supported >>>> platforms. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> On 10/10/2011 10:59 PM, Weijun Wang wrote: >>>>> I'm now running JPRT tests on this fix. >>>>> >>>>> Unfortunately, for the 6 finished tests, I've already seen linux-i586 >>>>> and solaris-i586 (both with c1 VM) failed on the new test with >>>>> >>>>> java.lang.OutOfMemoryError: Java heap space >>>>> >>>>> I guess our DER parsing codes are using too many memory. Maybe multiple >>>>> copies of huge byte array here and there. In the short term, I'll >>>>> see if >>>>> I can rewrite the test with othervm and a proper -Xmx option. >>>>> >>>>> Hopefully customer dealing with these huge CRLs always use c2 VM with >>>>> lots of memory. >>>>> >>>>> -Max >>>>> >>>>> On 10/10/2011 8:19 PM, Xuelei Fan wrote: >>>>>> Right! Then fine to me. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 10/11/2011 11:13 AM, Weijun Wang wrote: >>>>>>> 0xff will be 255, -1 means no byte to read, EOF. >>>>>>> >>>>>>> >>>>>>> On Oct 10, 2011, at 7:15 PM, Xuelei Fan >>>>>>> wrote: >>>>>>> >>>>>>>> I'm not sure why the latest byte cannot be 0xFF? What about if my >>>>>>>> content length is 256? For example: >>>>>>>> >>>>>>>> 677 if (lowByte == -1) { >>>>>>>> 678 throw new IOException("Incomplete BER/DER length info"); >>>>>>>> 679 } >>>>>>>> >>>>>>>> Otherwise, looks fine to me. >>>>>>>> >>>>>>>> Xuelei >>>>>>>> >>>>>>>> On 10/11/2011 9:05 AM, Weijun Wang wrote: >>>>>>>>> Webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.00/ >>>>>>>>> >>>>>>>>> Basically, we're now accepting X.509 block of 4-octets length. For >>>>>>>>> simplicity, the highest byte must be<= 127, so that the length >>>>>>>>> can be >>>>>>>>> expressed with a 32-bit int. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>> >>>>>>>>> -------- Original Message -------- >>>>>>>>> *Change Request ID*: 7099399 >>>>>>>>> *Synopsis*: cannot deal with CRL file larger than 16MB >>>>>>>>> >>>>>>>>> Product: java >>>>>>>>> Category: java >>>>>>>>> Subcategory: classes_security >>>>>>>>> Type: Defect >>>>>>>>> >>>>>>>>> === *Description* >>>>>>>>> ============================================================ >>>>>>>>> The X.509 impl of CertificateFactory only parses X.509 blocks >>>>>>>>> smaller >>>>>>>>> than 16MB, i.e. when the length can be encoded in 3 octets. Now we >>>>>>>>> have >>>>>>>>> a customer whose CRL file is as big as 30MB. >>>>>>>>> From fweimer at bfk.de Thu Oct 13 09:10:32 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 13 Oct 2011 09:10:32 +0000 Subject: updated code review request: 7099399: cannot deal with CRL file larger than 16MB In-Reply-To: <4E96A791.70906@oracle.com> (=?iso-8859-1?Q?=22Se=E1n?= Coffey"'s message of "Thu, 13 Oct 2011 09:55:45 +0100") References: <4E939659.3020406@oracle.com> <4E93A6CD.5050800@oracle.com> <4E93B5B3.80507@oracle.com> <4E93DB57.7060600@oracle.com> <4E94D20A.9030608@oracle.com> <4E95A1D9.8010605@oracle.com> <4E95E68E.7090206@oracle.com> <4E964479.3010703@oracle.com> <4E96A791.70906@oracle.com> Message-ID: <82lispuuif.fsf@mid.bfk.de> * Se?n Coffey: > Should this test be set to run manually ? > > 5 mins is far too long for a jtreg unit test IMO. If the visibility of the internal helper method is changed, you could test with a custom InputStream and ByteArrayOutputStream, which would cut down memory requirements. -- 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 From vincent.x.ryan at oracle.com Thu Oct 13 14:58:51 2011 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Thu, 13 Oct 2011 14:58:51 +0000 Subject: hg: jdk8/tl/jdk: 7099228: Use a PKCS11 config attribute to control encoding of an EC point Message-ID: <20111013145917.0FB9A47FDE@hg.openjdk.java.net> Changeset: 2b27e14a4c82 Author: vinnie Date: 2011-10-13 12:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2b27e14a4c82 7099228: Use a PKCS11 config attribute to control encoding of an EC point Reviewed-by: valeriep, mullan ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/lib/security/sunpkcs11-solaris.cfg ! test/ProblemList.txt From sean.mullan at oracle.com Thu Oct 13 18:14:19 2011 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 13 Oct 2011 18:14:19 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20111013181458.B1A5147FE2@hg.openjdk.java.net> Changeset: 01615d3e74ed Author: mullan Date: 2011-10-13 13:50 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01615d3e74ed 6953295: Move few sun.security.{util, x509, pkcs} classes used by keytool/jarsigner to another package Reviewed-by: mchung ! make/sun/security/other/Makefile - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java + src/share/classes/sun/security/pkcs10/PKCS10.java + src/share/classes/sun/security/pkcs10/PKCS10Attribute.java + src/share/classes/sun/security/pkcs10/PKCS10Attributes.java ! src/share/classes/sun/security/provider/certpath/CertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStoreHelper.java + src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStore.java + src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStoreHelper.java + src/share/classes/sun/security/tools/CertAndKeyGen.java ! src/share/classes/sun/security/tools/KeyTool.java + src/share/classes/sun/security/tools/PathList.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: 04ecbd2bcf5a Author: mullan Date: 2011-10-13 13:53 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/04ecbd2bcf5a Merge From weijun.wang at oracle.com Thu Oct 13 18:33:36 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 13 Oct 2011 11:33:36 -0700 Subject: updated code review request: 7099399: cannot deal with CRL file larger than 16MB In-Reply-To: <82lispuuif.fsf@mid.bfk.de> References: <4E939659.3020406@oracle.com> <4E93A6CD.5050800@oracle.com> <4E93B5B3.80507@oracle.com> <4E93DB57.7060600@oracle.com> <4E94D20A.9030608@oracle.com> <4E95A1D9.8010605@oracle.com> <4E95E68E.7090206@oracle.com> <4E964479.3010703@oracle.com> <4E96A791.70906@oracle.com> <82lispuuif.fsf@mid.bfk.de> Message-ID: <4E972F00.9060701@oracle.com> On 10/13/2011 2:10 AM, Florian Weimer wrote: > * Se?n Coffey: > >> Should this test be set to run manually ? >> >> 5 mins is far too long for a jtreg unit test IMO. Sorry, I was talking about the whole time for the job. I just go into each log to take a look at the exact time for the test itself. Most are less than 20 seconds, except for 3 solaris-sparc platforms, which are 105, 51 and 57 seconds. I guess this is still OK. > > If the visibility of the internal helper method is changed, you could > test with a custom InputStream and ByteArrayOutputStream, which would > cut down memory requirements. > Probably. Also, if required memory can be brought down, hopefully it will also decrease time. Thanks Max From weijun.wang at oracle.com Fri Oct 14 17:38:01 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 14 Oct 2011 10:38:01 -0700 Subject: Kerberos codes in Apple's Java Message-ID: <4E987379.1060501@oracle.com> Hi Mike I'm working in the Java SE Security Team in Oracle. Apple's JRE (at least in the JDK 6 releases) supports some extra Kerberos features for OS X. As I know, at least there are: 1. Looking for krb5.conf at /Library/Preferences/edu.mit.Kerberos 2. Reading native memory-based credentials cache into Credentials objects I didn't see them on the Project Status page [1]. Is it because they are too trivial to be listed or you're not going to support them? Thanks Max [1] http://wikis.sun.com/display/OpenJDK/Mac+OS+X+Port+Project+Status From bino at apple.com Sat Oct 15 00:50:02 2011 From: bino at apple.com (Bino George) Date: Fri, 14 Oct 2011 17:50:02 -0700 Subject: Kerberos codes in Apple's Java In-Reply-To: <4E987379.1060501@oracle.com> References: <4E987379.1060501@oracle.com> Message-ID: <34482A59-CDB2-4639-BB24-AF788D7C0BB0@apple.com> Hi Max, > 1. Looking for krb5.conf at /Library/Preferences/edu.mit.Kerberos I filed http://java.net/jira/browse/MACOSX_PORT-566 which tracks this feature. This should be fairly straight forward to port it from JDK6. We fixed JDK6 in Lion to also read the Kerberos config from SCDynamicStore as /Library/Preferences/edu.mit.Kerberos is not maintained in Lion. > 2. Reading native memory-based credentials cache into Credentials objects I don't think we do this in JDK6 either. Regards Bino. On Oct 14, 2011, at 10:38 AM, Weijun Wang wrote: > Hi Mike > > I'm working in the Java SE Security Team in Oracle. Apple's JRE (at least in the JDK 6 releases) supports some extra Kerberos features for OS X. As I know, at least there are: > > 1. Looking for krb5.conf at /Library/Preferences/edu.mit.Kerberos > 2. Reading native memory-based credentials cache into Credentials objects > > I didn't see them on the Project Status page [1]. Is it because they are too trivial to be listed or you're not going to support them? > > Thanks > Max > > [1] http://wikis.sun.com/display/OpenJDK/Mac+OS+X+Port+Project+Status -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Sat Oct 15 00:52:30 2011 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Fri, 14 Oct 2011 17:52:30 -0700 Subject: Code Review Needed: 7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine Message-ID: <4E98D94E.1040706@oracle.com> Hi Xuelei, I need code reviews for the bug I mentioned to you earlier. 7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine The MAC calculation was summing the wrong data range when using non-direct byte buffers and TLS1.1/1.2. The new regression test will now interop-test SSLEngine with SSLSockets using both direct and non-direct ByteBuffers, over SSLv3, TLSv1, TLSv1.1, and TLSv1.2. http://cr.openjdk.java.net/~wetmore/7031830/ I plan to push this to both JDK 8 and 7u2, so there are 2 webrevs there. They should be the same. Brad From bradford.wetmore at oracle.com Sat Oct 15 00:59:54 2011 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Fri, 14 Oct 2011 17:59:54 -0700 Subject: Code Review Needed: 7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine In-Reply-To: <4E98D94E.1040706@oracle.com> References: <4E98D94E.1040706@oracle.com> Message-ID: <4E98DB0A.5000009@oracle.com> I'll need a second codereviewer for the 7u2 change. Valerie/Sean/Max? Brad On 10/14/2011 5:52 PM, Brad Wetmore wrote: > Hi Xuelei, > > I need code reviews for the bug I mentioned to you earlier. > > 7031830: bad_record_mac failure on TLSv1.2 enabled connection with > SSLEngine > > The MAC calculation was summing the wrong data range when using > non-direct byte buffers and TLS1.1/1.2. > > The new regression test will now interop-test SSLEngine with SSLSockets > using both direct and non-direct ByteBuffers, over SSLv3, TLSv1, > TLSv1.1, and TLSv1.2. > > http://cr.openjdk.java.net/~wetmore/7031830/ > > I plan to push this to both JDK 8 and 7u2, so there are 2 webrevs there. > They should be the same. > > Brad From weijun.wang at oracle.com Sat Oct 15 01:55:01 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 14 Oct 2011 18:55:01 -0700 Subject: Kerberos codes in Apple's Java In-Reply-To: <34482A59-CDB2-4639-BB24-AF788D7C0BB0@apple.com> References: <4E987379.1060501@oracle.com> <34482A59-CDB2-4639-BB24-AF788D7C0BB0@apple.com> Message-ID: <536EDF08-F9C7-4C88-A709-8FFD9212F418@oracle.com> On Oct 14, 2011, at 5:50 PM, Bino George wrote: > Hi Max, > >> 1. Looking for krb5.conf at /Library/Preferences/edu.mit.Kerberos > > I filed http://java.net/jira/browse/MACOSX_PORT-566 which tracks this feature. This should be fairly straight forward to port it from JDK6. We fixed JDK6 in Lion to also read the Kerberos config from SCDynamicStore as /Library/Preferences/edu.mit.Kerberos is not maintained in Lion. Good. > >> 2. Reading native memory-based credentials cache into Credentials objects > > I don't think we do this in JDK6 either. Oh, I thought OS X's kinit does not generate a /tmp/krb5cc_name file. Isn't the ccache memory-based? Or, it's stored at somewhere else? Thanks Max > > Regards > Bino. > > > > On Oct 14, 2011, at 10:38 AM, Weijun Wang wrote: > >> Hi Mike >> >> I'm working in the Java SE Security Team in Oracle. Apple's JRE (at least in the JDK 6 releases) supports some extra Kerberos features for OS X. As I know, at least there are: >> >> 1. Looking for krb5.conf at /Library/Preferences/edu.mit.Kerberos >> 2. Reading native memory-based credentials cache into Credentials objects >> >> I didn't see them on the Project Status page [1]. Is it because they are too trivial to be listed or you're not going to support them? >> >> Thanks >> Max >> >> [1] http://wikis.sun.com/display/OpenJDK/Mac+OS+X+Port+Project+Status > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Sat Oct 15 02:23:02 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 15 Oct 2011 10:23:02 +0800 Subject: Code Review Needed: 7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine In-Reply-To: <4E98D94E.1040706@oracle.com> References: <4E98D94E.1040706@oracle.com> Message-ID: <4E98EE86.5070104@oracle.com> The change of SSLEngineImpl looks fine to me. In the new regression test: A. class name 28 * @run main/othervm SSLEngineTemplate 29 * 30 * SunJSSE does not support dynamic system properties, no way to re-use 31 * system properties in samevm/agentvm mode. I think the class name should be SSLEngineBadBufferArrayAccess. - 28 * @run main/othervm SSLEngineTemplate + 28 * @run main/othervm SSLEngineBadBufferArrayAccess B. a minor comment, reuse the serverEngine.wrap() logic. Is it possible to remove line 286 ~ 297, and have "while(!isEngineClosed())" handle the close notify? So that the server engine would be able to handle the client close_notify response. boolean exchangeHasDone = false; while (!isEngineClosed()) { 283 if (!exchangeHasDone && clientMsg.length == serverIn.position()) { // sanity check ... serverEngine.closeOutbound(); exchangeHasDone = true. } } catch (...) { Xuelei On 10/15/2011 8:52 AM, Brad Wetmore wrote: > Hi Xuelei, > > I need code reviews for the bug I mentioned to you earlier. > > 7031830: bad_record_mac failure on TLSv1.2 enabled connection with > SSLEngine > > The MAC calculation was summing the wrong data range when using > non-direct byte buffers and TLS1.1/1.2. > > The new regression test will now interop-test SSLEngine with SSLSockets > using both direct and non-direct ByteBuffers, over SSLv3, TLSv1, > TLSv1.1, and TLSv1.2. > > http://cr.openjdk.java.net/~wetmore/7031830/ > > I plan to push this to both JDK 8 and 7u2, so there are 2 webrevs there. > They should be the same. > > Brad From weijun.wang at oracle.com Mon Oct 17 09:12:16 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 17 Oct 2011 09:12:16 +0000 Subject: hg: jdk8/tl/jdk: 7099399: cannot deal with CRL file larger than 16MB Message-ID: <20111017091244.41C8347017@hg.openjdk.java.net> Changeset: 6cb07b35acf5 Author: weijun Date: 2011-10-17 17:11 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6cb07b35acf5 7099399: cannot deal with CRL file larger than 16MB Reviewed-by: xuelei, mullan ! src/share/classes/sun/security/provider/X509Factory.java + test/sun/security/provider/X509Factory/BigCRL.java From maurizio.cimadamore at oracle.com Mon Oct 17 11:59:44 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 17 Oct 2011 11:59:44 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20111017115950.696AA4701E@hg.openjdk.java.net> Changeset: b5d0b8effc85 Author: mcimadamore Date: 2011-10-17 12:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b5d0b8effc85 7097436: Project Coin: duplicate varargs warnings on method annotated with @SafeVarargs Summary: Duplicate aliasing check during subtyping leads to spurious varargs diagnostic Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/varargs/7097436/T7097436.java + test/tools/javac/varargs/7097436/T7097436.out ! test/tools/javac/varargs/warning/Warn5.java Changeset: 3cdfa97e1be9 Author: mcimadamore Date: 2011-10-17 12:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3cdfa97e1be9 7093325: Redundant entry in bytecode exception table Summary: Inlining of finalizers does not update gaps list accordingly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/T7093325.java From sean.mullan at oracle.com Mon Oct 17 18:51:50 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 17 Oct 2011 14:51:50 -0400 Subject: 7092897: sun.security.util.Cache should be generified Message-ID: <4E9C7946.3060108@oracle.com> Hi Xuelei, Would you be able to review this fix? http://cr.openjdk.java.net/~mullan/webrevs/7092897/webrev.00/ Thanks, Sean From bradford.wetmore at oracle.com Tue Oct 18 00:41:16 2011 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Mon, 17 Oct 2011 17:41:16 -0700 Subject: Code Review Needed: 7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine In-Reply-To: <4E98EE86.5070104@oracle.com> References: <4E98D94E.1040706@oracle.com> <4E98EE86.5070104@oracle.com> Message-ID: <4E9CCB2C.1040506@oracle.com> (Max/Valerie/Sean, I am hoping to get this into 7u2, thus need a second codereview. The code itself is pretty straightforward.) Xuelei wrote: > The change of SSLEngineImpl looks fine to me. > > In the new regression test: Changes made. Thanks for the feedback, Xuelei. I tweaked things a bit even more in the test case only. Now, I alternate between the client and the server initiating the closing. http://cr.openjdk.java.net/~wetmore/7031830/ See the .01 versions. Brad On 10/14/2011 7:23 PM, Xuelei Fan wrote: > The change of SSLEngineImpl looks fine to me. > > In the new regression test: > > A. class name > > 28 * @run main/othervm SSLEngineTemplate > 29 * > 30 * SunJSSE does not support dynamic system properties, no way to > re-use > 31 * system properties in samevm/agentvm mode. > > I think the class name should be SSLEngineBadBufferArrayAccess. > - 28 * @run main/othervm SSLEngineTemplate > + 28 * @run main/othervm SSLEngineBadBufferArrayAccess > > B. a minor comment, reuse the serverEngine.wrap() logic. > Is it possible to remove line 286 ~ 297, and have > "while(!isEngineClosed())" handle the close notify? So that the server > engine would be able to handle the client close_notify response. > > boolean exchangeHasDone = false; > while (!isEngineClosed()) { > 283 if (!exchangeHasDone&& clientMsg.length == serverIn.position()) { > // sanity check > ... > serverEngine.closeOutbound(); > exchangeHasDone = true. > } > } catch (...) { > > > Xuelei > > On 10/15/2011 8:52 AM, Brad Wetmore wrote: >> Hi Xuelei, >> >> I need code reviews for the bug I mentioned to you earlier. >> >> 7031830: bad_record_mac failure on TLSv1.2 enabled connection with >> SSLEngine >> >> The MAC calculation was summing the wrong data range when using >> non-direct byte buffers and TLS1.1/1.2. >> >> The new regression test will now interop-test SSLEngine with SSLSockets >> using both direct and non-direct ByteBuffers, over SSLv3, TLSv1, >> TLSv1.1, and TLSv1.2. >> >> http://cr.openjdk.java.net/~wetmore/7031830/ >> >> I plan to push this to both JDK 8 and 7u2, so there are 2 webrevs there. >> They should be the same. >> >> Brad > From xuelei.fan at oracle.com Tue Oct 18 01:02:22 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 18 Oct 2011 09:02:22 +0800 Subject: Code Review Needed: 7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine In-Reply-To: <4E9CCB2C.1040506@oracle.com> References: <4E98D94E.1040706@oracle.com> <4E98EE86.5070104@oracle.com> <4E9CCB2C.1040506@oracle.com> Message-ID: <4E9CD01E.8070104@oracle.com> Both (JDK 7u2 and JDK 8) look fine to me. Thanks for the update. Xuelei On 10/18/2011 8:41 AM, Brad Wetmore wrote: > (Max/Valerie/Sean, I am hoping to get this into 7u2, thus need a second > codereview. The code itself is pretty straightforward.) > > Xuelei wrote: >> The change of SSLEngineImpl looks fine to me. >> >> In the new regression test: > > Changes made. Thanks for the feedback, Xuelei. I tweaked things a bit > even more in the test case only. Now, I alternate between the client > and the server initiating the closing. > > http://cr.openjdk.java.net/~wetmore/7031830/ > > See the .01 versions. > > Brad > > > > > On 10/14/2011 7:23 PM, Xuelei Fan wrote: >> The change of SSLEngineImpl looks fine to me. >> >> In the new regression test: >> >> A. class name >> >> 28 * @run main/othervm SSLEngineTemplate >> 29 * >> 30 * SunJSSE does not support dynamic system properties, no way to >> re-use >> 31 * system properties in samevm/agentvm mode. >> >> I think the class name should be SSLEngineBadBufferArrayAccess. >> - 28 * @run main/othervm SSLEngineTemplate >> + 28 * @run main/othervm SSLEngineBadBufferArrayAccess >> >> B. a minor comment, reuse the serverEngine.wrap() logic. >> Is it possible to remove line 286 ~ 297, and have >> "while(!isEngineClosed())" handle the close notify? So that the server >> engine would be able to handle the client close_notify response. >> >> boolean exchangeHasDone = false; >> while (!isEngineClosed()) { >> 283 if (!exchangeHasDone&& clientMsg.length == serverIn.position()) { >> // sanity check >> ... >> serverEngine.closeOutbound(); >> exchangeHasDone = true. >> } >> } catch (...) { >> >> >> Xuelei >> >> On 10/15/2011 8:52 AM, Brad Wetmore wrote: >>> Hi Xuelei, >>> >>> I need code reviews for the bug I mentioned to you earlier. >>> >>> 7031830: bad_record_mac failure on TLSv1.2 enabled connection with >>> SSLEngine >>> >>> The MAC calculation was summing the wrong data range when using >>> non-direct byte buffers and TLS1.1/1.2. >>> >>> The new regression test will now interop-test SSLEngine with SSLSockets >>> using both direct and non-direct ByteBuffers, over SSLv3, TLSv1, >>> TLSv1.1, and TLSv1.2. >>> >>> http://cr.openjdk.java.net/~wetmore/7031830/ >>> >>> I plan to push this to both JDK 8 and 7u2, so there are 2 webrevs there. >>> They should be the same. >>> >>> Brad >> From weijun.wang at oracle.com Tue Oct 18 01:57:42 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 18 Oct 2011 09:57:42 +0800 Subject: Code Review Needed: 7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine In-Reply-To: <4E98DB0A.5000009@oracle.com> References: <4E98D94E.1040706@oracle.com> <4E98DB0A.5000009@oracle.com> Message-ID: <4E9CDD16.1090203@oracle.com> src looks fine. Not sure of test. So whenever you use socket on one side and engine on another, this bug will jump out? -Max On 10/15/2011 08:59 AM, Brad Wetmore wrote: > I'll need a second codereviewer for the 7u2 change. Valerie/Sean/Max? > > Brad > > > > On 10/14/2011 5:52 PM, Brad Wetmore wrote: >> Hi Xuelei, >> >> I need code reviews for the bug I mentioned to you earlier. >> >> 7031830: bad_record_mac failure on TLSv1.2 enabled connection with >> SSLEngine >> >> The MAC calculation was summing the wrong data range when using >> non-direct byte buffers and TLS1.1/1.2. >> >> The new regression test will now interop-test SSLEngine with SSLSockets >> using both direct and non-direct ByteBuffers, over SSLv3, TLSv1, >> TLSv1.1, and TLSv1.2. >> >> http://cr.openjdk.java.net/~wetmore/7031830/ >> >> I plan to push this to both JDK 8 and 7u2, so there are 2 webrevs there. >> They should be the same. >> >> Brad From bradford.wetmore at oracle.com Tue Oct 18 03:00:19 2011 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Mon, 17 Oct 2011 20:00:19 -0700 Subject: Code Review Needed: 7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine In-Reply-To: <4E9CDD16.1090203@oracle.com> References: <4E98D94E.1040706@oracle.com> <4E98DB0A.5000009@oracle.com> <4E9CDD16.1090203@oracle.com> Message-ID: <4E9CEBC3.4090305@oracle.com> Thanks Max/Andrew! On 10/17/2011 6:57 PM, Weijun Wang wrote: > src looks fine. > > Not sure of test. So whenever you use socket on one side and engine on > another, this bug will jump out? If you use a SSLsocket on side, and an SSLEngine on the other, and the engine is using target ByteBuffers that are backed by a Java ByteArray (i.e. ByteBuffer.hasArray() == true), this bug will jump out. At least in the Oracle JDK in my basic testing, this includes "regular" byte buffers (ByteBuffer.allocate(), but not ByteBuffer.allocateDirect()) Note this also only occurs on TLS 1.1/1.2, as the new IV field isn't being properly handled. Brad > -Max > > On 10/15/2011 08:59 AM, Brad Wetmore wrote: >> I'll need a second codereviewer for the 7u2 change. Valerie/Sean/Max? >> >> Brad >> >> >> >> On 10/14/2011 5:52 PM, Brad Wetmore wrote: >>> Hi Xuelei, >>> >>> I need code reviews for the bug I mentioned to you earlier. >>> >>> 7031830: bad_record_mac failure on TLSv1.2 enabled connection with >>> SSLEngine >>> >>> The MAC calculation was summing the wrong data range when using >>> non-direct byte buffers and TLS1.1/1.2. >>> >>> The new regression test will now interop-test SSLEngine with SSLSockets >>> using both direct and non-direct ByteBuffers, over SSLv3, TLSv1, >>> TLSv1.1, and TLSv1.2. >>> >>> http://cr.openjdk.java.net/~wetmore/7031830/ >>> >>> I plan to push this to both JDK 8 and 7u2, so there are 2 webrevs there. >>> They should be the same. >>> >>> Brad From xuelei.fan at oracle.com Tue Oct 18 03:07:25 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 18 Oct 2011 11:07:25 +0800 Subject: 7092897: sun.security.util.Cache should be generified In-Reply-To: <4E9C7946.3060108@oracle.com> References: <4E9C7946.3060108@oracle.com> Message-ID: <4E9CED6D.9020904@oracle.com> I only have a few very minor suggestions. in sun/security/util/Cache.java: -> 264 this.queue = soft ? new ReferenceQueue() : null; ^ I would like to remove the generic "V" in the right side of the assignment: 264 this.queue = soft ? new ReferenceQueue<>() : null; -> 255 private final ReferenceQueue queue; ^ >From my first look at the update, I think the real generic type should be "CacheEntry", instead of "V". However, because SoftCacheEntry class need to extend SoftReference, we have to use a dummy type "V" here. I was wondering we may want to add a line or two comments here. Otherwise, looks fine to me. Xuelei On 10/18/2011 2:51 AM, Sean Mullan wrote: > Hi Xuelei, > > Would you be able to review this fix? > > http://cr.openjdk.java.net/~mullan/webrevs/7092897/webrev.00/ > > Thanks, > Sean From sean.mullan at oracle.com Tue Oct 18 13:12:30 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 18 Oct 2011 09:12:30 -0400 Subject: 7092897: sun.security.util.Cache should be generified In-Reply-To: <4E9CED6D.9020904@oracle.com> References: <4E9C7946.3060108@oracle.com> <4E9CED6D.9020904@oracle.com> Message-ID: <4E9D7B3E.8020605@oracle.com> On 10/17/11 11:07 PM, Xuelei Fan wrote: > I only have a few very minor suggestions. > > in sun/security/util/Cache.java: > -> 264 this.queue = soft ? new ReferenceQueue() : null; > ^ > I would like to remove the generic "V" in the right side of the assignment: > 264 this.queue = soft ? new ReferenceQueue<>() : null; I tried that, but I get a compiler error: ../../../../src/share/classes/sun/security/util/Cache.java:264: error: incompatible types this.queue = soft ? new ReferenceQueue<>() : null; ^ required: ReferenceQueue found: ReferenceQueue where V is a type-variable: V extends Object declared in class MemoryCache 1 error I think it may be a bug in the compiler though, because if I break out the code like this: if (soft) this.queue = new ReferenceQueue<>(); else this.queue = null; I don't get an error. I'll look into filing a compiler bug on this, but in the meantime, I'll change the code to the above. > -> 255 private final ReferenceQueue queue; > ^ > From my first look at the update, I think the real generic type should > be "CacheEntry", instead of "V". However, because SoftCacheEntry > class need to extend SoftReference, we have to use a dummy type "V" > here. I was wondering we may want to add a line or two comments here. Good point. I will add some comments. Thanks, Sean > > > Otherwise, looks fine to me. > > Xuelei > > On 10/18/2011 2:51 AM, Sean Mullan wrote: >> Hi Xuelei, >> >> Would you be able to review this fix? >> >> http://cr.openjdk.java.net/~mullan/webrevs/7092897/webrev.00/ >> >> Thanks, >> Sean > From sean.mullan at oracle.com Tue Oct 18 14:35:48 2011 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 18 Oct 2011 14:35:48 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20111018143617.B1F554703C@hg.openjdk.java.net> Changeset: 9bf526cc4046 Author: mullan Date: 2011-10-18 10:12 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9bf526cc4046 7092897: sun.security.util.Cache should be generified Reviewed-by: xuelei ! src/share/classes/sun/security/pkcs11/KeyCache.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/provider/certpath/CertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/X509CertificatePair.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/util/Cache.java Changeset: f566cd364a90 Author: mullan Date: 2011-10-18 10:15 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f566cd364a90 Merge ! src/share/classes/sun/security/provider/X509Factory.java From bradford.wetmore at oracle.com Tue Oct 18 19:03:49 2011 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Tue, 18 Oct 2011 19:03:49 +0000 Subject: hg: jdk8/tl/jdk: 7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine Message-ID: <20111018190407.093524703E@hg.openjdk.java.net> Changeset: 8640b7185be1 Author: wetmore Date: 2011-10-18 11:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8640b7185be1 7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine Reviewed-by: xuelei, weijun, asaha ! src/share/classes/sun/security/ssl/CipherBox.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java From sean.mullan at oracle.com Wed Oct 19 14:29:53 2011 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 19 Oct 2011 14:29:53 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20111019143023.0F3A94707E@hg.openjdk.java.net> Changeset: 57eb9136b73b Author: mullan Date: 2011-10-19 10:15 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57eb9136b73b 7102686: Restructure timestamp code so that jars and modules can more easily share the same code Reviewed-by: mchung ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/pkcs/SignerInfo.java ! src/share/classes/sun/security/timestamp/HttpTimestamper.java ! src/share/classes/sun/security/timestamp/TSRequest.java ! src/share/classes/sun/security/timestamp/TSResponse.java ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/TimestampedSigner.java ! src/share/classes/sun/security/util/Debug.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java Changeset: 15078025eed9 Author: mullan Date: 2011-10-19 10:16 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/15078025eed9 Merge From maurizio.cimadamore at oracle.com Wed Oct 19 15:57:10 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 19 Oct 2011 15:57:10 +0000 Subject: hg: jdk8/tl/langtools: 7102515: javac running very very long and not returning Message-ID: <20111019155714.7885247085@hg.openjdk.java.net> Changeset: 366c233eb838 Author: mcimadamore Date: 2011-10-19 16:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/366c233eb838 7102515: javac running very very long and not returning Summary: Verbose resolution diagnostics slow down with operator resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/7102515/T7102515.java + test/tools/javac/7102515/T7102515.out From mike.duigou at oracle.com Wed Oct 19 22:23:44 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 19 Oct 2011 22:23:44 +0000 Subject: hg: jdk8/tl/jdk: 5029031: Add Collections.checkedQueue() Message-ID: <20111019222354.E00AF47099@hg.openjdk.java.net> Changeset: c5c91589b126 Author: mduigou Date: 2011-10-19 14:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c5c91589b126 5029031: Add Collections.checkedQueue() Reviewed-by: mduigou Contributed-by: darryl.mocek at oracle.com ! src/share/classes/java/util/Collections.java + test/java/util/Collections/CheckedQueue.java From jonathan.gibbons at oracle.com Wed Oct 19 22:30:02 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 19 Oct 2011 22:30:02 +0000 Subject: hg: jdk8/tl/langtools: 7101146: Paths should more directly managed by BaseFileManager Message-ID: <20111019223004.5AD124709A@hg.openjdk.java.net> Changeset: d2cbb77469ed Author: jjg Date: 2011-10-19 15:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d2cbb77469ed 7101146: Paths should more directly managed by BaseFileManager Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java From chris.hegarty at oracle.com Thu Oct 20 08:09:09 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 20 Oct 2011 08:09:09 +0000 Subject: hg: jdk8/tl/jdk: 7102704: test/java/net/DatagramSocket/ChangingAddress.java failing Message-ID: <20111020080928.DE1124709B@hg.openjdk.java.net> Changeset: 634cd6f050ba Author: chegar Date: 2011-10-20 09:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/634cd6f050ba 7102704: test/java/net/DatagramSocket/ChangingAddress.java failing Reviewed-by: chegar Contributed-by: kurchi.subhra.hazra at oracle.com - test/java/net/DatagramSocket/ChangingAddress.java From michael.x.mcmahon at oracle.com Thu Oct 20 08:27:19 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 20 Oct 2011 08:27:19 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20111020082739.7BD904709D@hg.openjdk.java.net> Changeset: 2d89c3f74aa5 Author: michaelm Date: 2011-10-20 09:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2d89c3f74aa5 7102665: Move tests to Problemlist Reviewed-by: chegar, alanb ! test/ProblemList.txt Changeset: 52c2dd336207 Author: michaelm Date: 2011-10-20 09:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/52c2dd336207 Merge - test/java/net/DatagramSocket/ChangingAddress.java From neil.richards at ngmr.net Thu Oct 20 13:56:22 2011 From: neil.richards at ngmr.net (neil.richards at ngmr.net) Date: Thu, 20 Oct 2011 13:56:22 +0000 Subject: hg: jdk8/tl/jdk: 7100054: (porting) Native code should include fcntl.h and unistd.h rather than sys/fcntl.h and sys/unistd.h Message-ID: <20111020135641.19E52470A4@hg.openjdk.java.net> Changeset: c3da0672a882 Author: ngmr Date: 2011-10-13 12:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c3da0672a882 7100054: (porting) Native code should include fcntl.h and unistd.h rather than sys/fcntl.h and sys/unistd.h Summary: Use POSIX defined includes for unistd.h and fcntl.h Reviewed-by: dholmes, alanb, chegar, ngmr Contributed-by: Charles Lee ! src/solaris/native/sun/nio/fs/genSolarisConstants.c ! src/solaris/native/sun/nio/fs/genUnixConstants.c From yuka.kamiya at oracle.com Fri Oct 21 06:58:42 2011 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Fri, 21 Oct 2011 06:58:42 +0000 Subject: hg: jdk8/tl/jdk: 7103108: (tz) Support tzdata2011l Message-ID: <20111021065900.1404D470BC@hg.openjdk.java.net> Changeset: d979afceb792 Author: peytoia Date: 2011-10-21 15:56 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d979afceb792 7103108: (tz) Support tzdata2011l Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java From yuka.kamiya at oracle.com Fri Oct 21 09:03:07 2011 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Fri, 21 Oct 2011 09:03:07 +0000 Subject: hg: jdk8/tl/jdk: 7103405: Correct display names for Pacific/Apia timezone Message-ID: <20111021090324.B86FD470BE@hg.openjdk.java.net> Changeset: db9e246c651e Author: peytoia Date: 2011-10-21 18:01 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db9e246c651e 7103405: Correct display names for Pacific/Apia timezone Reviewed-by: okutsu ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java From chris.hegarty at oracle.com Fri Oct 21 15:43:08 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 21 Oct 2011 16:43:08 +0100 Subject: Code Review 7103549: Remove dependencies on libjava and libjvm from security libraries Message-ID: <4EA1930C.9020106@oracle.com> All of the security native libraries have runtime dependencies on libjava and libjvm, most of which are completely unnecessary. This CR proposes to remove these dependencies and provide localized versions of the trivial utility functions that are being used from libjava, i.e. the JNU_ThrowXXX functions. There is also a dependency on JNI_GetCreatedJavaVMs which can easily be removed by caching a reference to the JavaVM when the library is loaded, in JNI_OnLoad, and making this reference available within the library itself. http://cr.openjdk.java.net/~chegar/7103549/webrev.oo/webrev/ -Chris. From vincent.x.ryan at oracle.com Fri Oct 21 17:01:06 2011 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 21 Oct 2011 18:01:06 +0100 Subject: Code Review 7103549: Remove dependencies on libjava and libjvm from security libraries In-Reply-To: <4EA1930C.9020106@oracle.com> References: <4EA1930C.9020106@oracle.com> Message-ID: <4EA1A552.8010004@oracle.com> Those changes look fine. On 10/21/11 04:43 PM, Chris Hegarty wrote: > All of the security native libraries have runtime dependencies on libjava and > libjvm, most of which are completely unnecessary. This CR proposes to remove > these dependencies and provide localized versions of the trivial utility > functions that are being used from libjava, i.e. the JNU_ThrowXXX functions. > > There is also a dependency on JNI_GetCreatedJavaVMs which can easily be removed > by caching a reference to the JavaVM when the library is loaded, in JNI_OnLoad, > and making this reference available within the library itself. > > http://cr.openjdk.java.net/~chegar/7103549/webrev.oo/webrev/ > > -Chris. From jim.holmlund at sun.com Fri Oct 21 21:17:46 2011 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Fri, 21 Oct 2011 21:17:46 +0000 Subject: hg: jdk8/tl/langtools: 7098530: tools/javac/javazip/Test.sh can fail on Windows Message-ID: <20111021211751.BDCCB470CB@hg.openjdk.java.net> Changeset: b4021c520e40 Author: jjh Date: 2011-10-21 14:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b4021c520e40 7098530: tools/javac/javazip/Test.sh can fail on Windows Summary: Fix cygpath command to properly convert path Reviewed-by: jjg ! test/tools/javac/javazip/Test.sh From Alan.Bateman at oracle.com Sat Oct 22 14:03:49 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 22 Oct 2011 15:03:49 +0100 Subject: Code Review 7103549: Remove dependencies on libjava and libjvm from security libraries In-Reply-To: <4EA1930C.9020106@oracle.com> References: <4EA1930C.9020106@oracle.com> Message-ID: <4EA2CD45.5020704@oracle.com> Chris Hegarty wrote: > All of the security native libraries have runtime dependencies on > libjava and libjvm, most of which are completely unnecessary. This CR > proposes to remove these dependencies and provide localized versions > of the trivial utility functions that are being used from libjava, > i.e. the JNU_ThrowXXX functions. > > There is also a dependency on JNI_GetCreatedJavaVMs which can easily > be removed by caching a reference to the JavaVM when the library is > loaded, in JNI_OnLoad, and making this reference available within the > library itself. > > http://cr.openjdk.java.net/~chegar/7103549/webrev.oo/webrev/ > > -Chris. Just to put more context on this, one of the prerequisites to splitting the JDK into a set of modules with native libraries that live in per-module directories is that we eliminate the dependencies between native libraries that will, in all likelihood, be in separate modules. I prototyped the JDK changes some time ago but didn't have time to get over the finish time. Chris has agreed to take up the running on this so this is the first of several changes to address these dependencies. Chris - looks good to me and thanks for taking this. Minor comment on the comment in Defs.gmk (and I know this will go away once all the changes are in) is that the comment "A list of Programs' makefiles" might be better as "The makefiles for these packages do not link against libjvm and libjava". -Alan. From david.holmes at oracle.com Sun Oct 23 22:43:17 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 24 Oct 2011 08:43:17 +1000 Subject: Code Review 7103549: Remove dependencies on libjava and libjvm from security libraries In-Reply-To: <4EA1930C.9020106@oracle.com> References: <4EA1930C.9020106@oracle.com> Message-ID: <4EA49885.4010600@oracle.com> Hi Chris, On 22/10/2011 1:43 AM, Chris Hegarty wrote: > All of the security native libraries have runtime dependencies on > libjava and libjvm, most of which are completely unnecessary. This CR > proposes to remove these dependencies and provide localized versions of > the trivial utility functions that are being used from libjava, i.e. the > JNU_ThrowXXX functions. > > There is also a dependency on JNI_GetCreatedJavaVMs which can easily be > removed by caching a reference to the JavaVM when the library is loaded, > in JNI_OnLoad, and making this reference available within the library > itself. > > http://cr.openjdk.java.net/~chegar/7103549/webrev.oo/webrev/ In make/sun/security/krb5/Makefile you dropped -ldl - was that intentional? Otherwise looks ok to me. David > -Chris. From weijun.wang at oracle.com Mon Oct 24 01:52:25 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 24 Oct 2011 09:52:25 +0800 Subject: Is there an algorithm that computes the strength of a digest alg? Message-ID: <4EA4C4D9.2030905@oracle.com> Hi Andrew I need a method boolean isWeakerThan(String a1, String a2) so that isWeakerThan("MD5", "SHA1") returns true and isWeakerThan("SHA-256", "SHA1") returns false. I know you have done a lot of constraints works in JDK 7. Do you have an existing one? Otherwise, I plan to manually assign a value to each known algorithm and compare it. Thanks Max From mstjohns at comcast.net Mon Oct 24 03:03:10 2011 From: mstjohns at comcast.net (Michael StJohns) Date: Sun, 23 Oct 2011 23:03:10 -0400 Subject: Is there an algorithm that computes the strength of a digest alg? In-Reply-To: <4EA4C4D9.2030905@oracle.com> References: <4EA4C4D9.2030905@oracle.com> Message-ID: <20111024030312.79ADD6FCA@mail.openjdk.java.net> Assuming that a1 and a2 both refer to MessageDigest implementations, then you could simply compare MessageDigest.getInstance(a1).getDigestLength(). It won't give you an absolute - MD5 for example is weaker than its bit length would lead you to believe. Also, getDigestLength() can return 0 to indicate the operation isn't supported, so building a table may just be easier. Mike At 09:52 PM 10/23/2011, Weijun Wang wrote: >Hi Andrew > >I need a method > > boolean isWeakerThan(String a1, String a2) > >so that isWeakerThan("MD5", "SHA1") returns true and isWeakerThan("SHA-256", "SHA1") returns false. I know you have done a lot of constraints works in JDK 7. Do you have an existing one? Otherwise, I plan to manually assign a value to each known algorithm and compare it. > >Thanks >Max From xuelei.fan at oracle.com Mon Oct 24 03:24:47 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 24 Oct 2011 11:24:47 +0800 Subject: Is there an algorithm that computes the strength of a digest alg? In-Reply-To: <4EA4C4D9.2030905@oracle.com> References: <4EA4C4D9.2030905@oracle.com> Message-ID: <4EA4DA7F.8080807@oracle.com> I don't think we have similar methods. I was wondering, sometimes, we may not be able to compare the strength of two hash functions strictly. There are different "attacks" on different hash functions. One hash function maybe safe to one attack method but may be weak for another attack method. In another case, before 2004 (SHA-1 is reported broken this year), we can say SHA-1 is "stronger" than "MD2". But now, we may not be able to say it any more, because it is a little easier (in complexity) to crack SHA-1 than MD2 according to some researchs. Xuelei On 10/24/2011 9:52 AM, Weijun Wang wrote: > Hi Andrew > > I need a method > > boolean isWeakerThan(String a1, String a2) > > so that isWeakerThan("MD5", "SHA1") returns true and > isWeakerThan("SHA-256", "SHA1") returns false. I know you have done a > lot of constraints works in JDK 7. Do you have an existing one? > Otherwise, I plan to manually assign a value to each known algorithm and > compare it. > > Thanks > Max From bradford.wetmore at oracle.com Mon Oct 24 03:39:28 2011 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Sun, 23 Oct 2011 20:39:28 -0700 Subject: Is there an algorithm that computes the strength of a digest alg? In-Reply-To: <4EA4C4D9.2030905@oracle.com> References: <4EA4C4D9.2030905@oracle.com> Message-ID: <4EA4DDF0.4070602@oracle.com> I don't know of anything like that. As Michael points out, key Lengths by themselves are not always a good indicator of relative stength. BTW, JSSE hard-codes the choices. Brad On 10/23/2011 6:52 PM, Weijun Wang wrote: > Hi Andrew > > I need a method > > boolean isWeakerThan(String a1, String a2) > > so that isWeakerThan("MD5", "SHA1") returns true and > isWeakerThan("SHA-256", "SHA1") returns false. I know you have done a > lot of constraints works in JDK 7. Do you have an existing one? > Otherwise, I plan to manually assign a value to each known algorithm and > compare it. > > Thanks > Max From chris.hegarty at oracle.com Mon Oct 24 08:07:48 2011 From: chris.hegarty at oracle.com (chris hegarty) Date: Mon, 24 Oct 2011 09:07:48 +0100 Subject: Code Review 7103549: Remove dependencies on libjava and libjvm from security libraries In-Reply-To: <4EA49885.4010600@oracle.com> References: <4EA1930C.9020106@oracle.com> <4EA49885.4010600@oracle.com> Message-ID: <4EA51CD4.7030508@oracle.com> On 23/10/2011 23:43, David Holmes wrote: > Hi Chris, > > On 22/10/2011 1:43 AM, Chris Hegarty wrote: >> All of the security native libraries have runtime dependencies on >> libjava and libjvm, most of which are completely unnecessary. This CR >> proposes to remove these dependencies and provide localized versions of >> the trivial utility functions that are being used from libjava, i.e. the >> JNU_ThrowXXX functions. >> >> There is also a dependency on JNI_GetCreatedJavaVMs which can easily be >> removed by caching a reference to the JavaVM when the library is loaded, >> in JNI_OnLoad, and making this reference available within the library >> itself. >> >> http://cr.openjdk.java.net/~chegar/7103549/webrev.oo/webrev/ > > In make/sun/security/krb5/Makefile you dropped -ldl - was that intentional? Yes, this was just a little cleanup. I noticed that there was no dependency on libdl.so from this library. I suspect this may have original just been copied form another makefile. In fact, the dlopen, dlsym, etc, functions (that are the usually the cause for linking against ldl) are part of the standard C library functions on Solaris, so ldl could be Linux specific. But I didn't want to get too much involved in cleanup here. -Chris. > > Otherwise looks ok to me. > > David > >> -Chris. From maurizio.cimadamore at oracle.com Mon Oct 24 12:01:45 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 24 Oct 2011 12:01:45 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20111024120150.23AE5470F5@hg.openjdk.java.net> Changeset: d346ab55031b Author: mcimadamore Date: 2011-10-24 13:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d346ab55031b 7096014: Javac tokens should retain state Summary: Refactor javac tokens from enum constants to stateful instances (to keep track of position, comments, etc.) Reviewed-by: jjg ! src/share/classes/com/sun/tools/apt/main/AptJavaCompiler.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java ! src/share/classes/com/sun/tools/javac/parser/EndPosParser.java + src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java ! src/share/classes/com/sun/tools/javac/parser/Lexer.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/ScannerFactory.java - src/share/classes/com/sun/tools/javac/parser/Token.java + src/share/classes/com/sun/tools/javac/parser/Tokens.java + src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! test/tools/javac/api/TestJavacTaskScanner.java + test/tools/javac/depDocComment/DeprecatedDocComment3.java + test/tools/javac/tree/DocCommentToplevelTest.java Changeset: 05814303a056 Author: mcimadamore Date: 2011-10-24 13:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/05814303a056 7098660: Write better overload resolution/inference tests Summary: Add overload/inference debug diagnostics - added test harness using annotations to check outcome of overload resolution/inference Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Printer.java ! 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/ApplicableMethodFound.java + test/tools/javac/diags/examples/ApplicableMethodFound1.java + test/tools/javac/diags/examples/DeferredMethodInst.java + test/tools/javac/diags/examples/FullInstSig.java + test/tools/javac/diags/examples/NotApplicableMethodFound.java + test/tools/javac/diags/examples/PartialInstSig.java + test/tools/javac/diags/examples/VerboseResolveMulti.java + test/tools/javac/diags/examples/VerboseResolveMulti1.java + test/tools/javac/resolve/Candidate.java + test/tools/javac/resolve/Pos.java + test/tools/javac/resolve/ResolveHarness.java + test/tools/javac/resolve/TraceResolve.java + test/tools/javac/resolve/tests/BoxedReturnTypeInference.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceOverInferred.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceOverVarargs.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceVarargsAmbiguous.java + test/tools/javac/resolve/tests/PrimitiveOverload.java + test/tools/javac/resolve/tests/PrimitiveReturnTypeInference.java + test/tools/javac/resolve/tests/ReferenceOverInferred.java + test/tools/javac/resolve/tests/ReferenceOverVarargs.java + test/tools/javac/resolve/tests/ReferenceOverload.java From chris.hegarty at oracle.com Mon Oct 24 19:56:24 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 24 Oct 2011 19:56:24 +0000 Subject: hg: jdk8/tl/jdk: 7104209: Cleanup and remove librmi (native library) Message-ID: <20111024195647.20EB547103@hg.openjdk.java.net> Changeset: 3f391e649ccb Author: chegar Date: 2011-10-24 20:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f391e649ccb 7104209: Cleanup and remove librmi (native library) Reviewed-by: mduigou, alanb ! make/java/java/mapfile-vers ! make/sun/rmi/rmi/Makefile - make/sun/rmi/rmi/mapfile-vers ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/rmi/server/MarshalInputStream.java ! src/share/native/java/io/ObjectInputStream.c ! src/share/native/sun/misc/VM.c - src/share/native/sun/rmi/server/MarshalInputStream.c From chris.hegarty at oracle.com Mon Oct 24 20:05:15 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 24 Oct 2011 20:05:15 +0000 Subject: hg: jdk8/tl/jdk: 7103549: Remove dependencies on libjava and libjvm from security libraries Message-ID: <20111024200525.F3B6B47104@hg.openjdk.java.net> Changeset: b375523d6037 Author: chegar Date: 2011-10-24 21:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b375523d6037 7103549: Remove dependencies on libjava and libjvm from security libraries Reviewed-by: vinnie, ohair, alanb, dholmes ! make/com/sun/security/auth/module/Makefile ! make/common/Defs.gmk ! make/common/Library.gmk ! make/sun/security/ec/Makefile ! make/sun/security/jgss/wrapper/Makefile ! make/sun/security/krb5/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! make/sun/security/smartcardio/Makefile ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_dual.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h ! src/solaris/native/sun/security/pkcs11/j2secmod_md.c ! src/solaris/native/sun/security/smartcardio/pcsc_md.c ! src/windows/native/sun/security/pkcs11/j2secmod_md.c From brich at us.ibm.com Mon Oct 24 15:34:44 2011 From: brich at us.ibm.com (Bruce Rich) Date: Mon, 24 Oct 2011 10:34:44 -0500 Subject: Is there an algorithm that computes the strength of a digest alg? In-Reply-To: <4EA4DDF0.4070602@oracle.com> References: <4EA4C4D9.2030905@oracle.com> <4EA4DDF0.4070602@oracle.com> Message-ID: For the algorithms that NIST recognizes and approves, the doc linked below has some strength comparisons in tables near page 60 http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf Bruce A Rich brich at-sign us dot ibm dot com From: Bradford Wetmore To: Weijun Wang Cc: "Xuelei.Fan at oracle.com" , OpenJDK Date: 10/23/2011 10:47 PM Subject: Re: Is there an algorithm that computes the strength of a digest alg? Sent by: security-dev-bounces at openjdk.java.net I don't know of anything like that. As Michael points out, key Lengths by themselves are not always a good indicator of relative stength. BTW, JSSE hard-codes the choices. Brad On 10/23/2011 6:52 PM, Weijun Wang wrote: > Hi Andrew > > I need a method > > boolean isWeakerThan(String a1, String a2) > > so that isWeakerThan("MD5", "SHA1") returns true and > isWeakerThan("SHA-256", "SHA1") returns false. I know you have done a > lot of constraints works in JDK 7. Do you have an existing one? > Otherwise, I plan to manually assign a value to each known algorithm and > compare it. > > Thanks > Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlosna at gmail.com Tue Oct 25 02:15:51 2011 From: schlosna at gmail.com (David Schlosnagle) Date: Mon, 24 Oct 2011 22:15:51 -0400 Subject: Is there an algorithm that computes the strength of a digest alg? In-Reply-To: References: <4EA4C4D9.2030905@oracle.com> <4EA4DDF0.4070602@oracle.com> Message-ID: You may also want to refer to the following two NIST documents currently in draft status: ?* SP 800-107 Revised Recommendation for Applications Using Approved Hash Algorithms (comments due by the end of October) [1] - See Table 1: Strengths of the Security Properties of the Approved Hash Algorithms ?* FIPS 180-4: Secure Hash Standard (SHS) [2] [1]: http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-107-Revised [2]: http://csrc.nist.gov/publications/PubsDrafts.html#FIPS-180--4 - Dave On Mon, Oct 24, 2011 at 11:34 AM, Bruce Rich wrote: > For the algorithms that NIST recognizes and approves, the doc linked below > has some strength comparisons in tables near page 60 > > http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf > > Bruce A Rich > brich at-sign us dot ibm dot com > > > > > From: ? ? ? ?Bradford Wetmore > To: ? ? ? ?Weijun Wang > Cc: ? ? ? ?"Xuelei.Fan at oracle.com" , OpenJDK > > Date: ? ? ? ?10/23/2011 10:47 PM > Subject: ? ? ? ?Re: Is there an algorithm that computes the strength of a > digest alg? > Sent by: ? ? ? ?security-dev-bounces at openjdk.java.net > ________________________________ > > > I don't know of anything like that. ?As Michael points out, key Lengths > by themselves are not always a good indicator of relative stength. > > BTW, JSSE hard-codes the choices. > > Brad > > > > > On 10/23/2011 6:52 PM, Weijun Wang wrote: >> Hi Andrew >> >> I need a method >> >> boolean isWeakerThan(String a1, String a2) >> >> so that isWeakerThan("MD5", "SHA1") returns true and >> isWeakerThan("SHA-256", "SHA1") returns false. I know you have done a >> lot of constraints works in JDK 7. Do you have an existing one? >> Otherwise, I plan to manually assign a value to each known algorithm and >> compare it. >> >> Thanks >> Max > > > From alan.bateman at oracle.com Tue Oct 25 08:28:38 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 25 Oct 2011 08:28:38 +0000 Subject: hg: jdk8/tl/jdk: 7104577: Changes for 7104209 cause many RMI tests to fail Message-ID: <20111025082859.73ED547109@hg.openjdk.java.net> Changeset: 72666cd49ac3 Author: alanb Date: 2011-10-25 09:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72666cd49ac3 7104577: Changes for 7104209 cause many RMI tests to fail Reviewed-by: chegar ! src/share/classes/sun/rmi/server/MarshalInputStream.java From maurizio.cimadamore at oracle.com Tue Oct 25 14:41:55 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 25 Oct 2011 14:41:55 +0000 Subject: hg: jdk8/tl/langtools: 7104618: MessageInfo.java is failing after lexer changes Message-ID: <20111025144200.CE2C647112@hg.openjdk.java.net> Changeset: b73a9be0b993 Author: mcimadamore Date: 2011-10-25 15:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b73a9be0b993 7104618: MessageInfo.java is failing after lexer changes Summary: Two langtools regression tests cannot be built due to a bad import statement Reviewed-by: jjg ! test/tools/javac/diags/ArgTypeCompilerFactory.java From jonathan.gibbons at oracle.com Tue Oct 25 17:48:46 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 25 Oct 2011 17:48:46 +0000 Subject: hg: jdk8/tl/langtools: 7104039: refactor/cleanup javac Paths class Message-ID: <20111025174848.C198547115@hg.openjdk.java.net> Changeset: d830d28fc72e Author: jjg Date: 2011-10-25 10:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d830d28fc72e 7104039: refactor/cleanup javac Paths class Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java + src/share/classes/com/sun/tools/javac/file/Locations.java - src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java From jim.holmlund at sun.com Wed Oct 26 02:19:45 2011 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Wed, 26 Oct 2011 02:19:45 +0000 Subject: hg: jdk8/tl/langtools: 7104905: Java SE build fails on call to CreateSymbols Message-ID: <20111026021948.C5E5447123@hg.openjdk.java.net> Changeset: a1eaf78ababb Author: jjh Date: 2011-10-25 19:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a1eaf78ababb 7104905: Java SE build fails on call to CreateSymbols Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/file/Locations.java From sean.mullan at oracle.com Wed Oct 26 12:54:00 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 26 Oct 2011 08:54:00 -0400 Subject: 7094155 Code Review Request Message-ID: <4EA802E8.6080505@oracle.com> Hi Xuelei, Could you please review my fix for 7094155 (JSR105 code throws javax.xml.crypto.URIReference when running into Java 7 VM)? webrev: http://cr.openjdk.java.net/~mullan/webrevs/7094155/webrev.00/ Thanks, Sean From chris.hegarty at oracle.com Wed Oct 26 12:59:30 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 26 Oct 2011 12:59:30 +0000 Subject: hg: jdk8/tl/jdk: 7104650: rawtype warnings in several net, nio and security source files Message-ID: <20111026125941.92FCD47129@hg.openjdk.java.net> Changeset: 88a260444e4d Author: chegar Date: 2011-10-26 13:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/88a260444e4d 7104650: rawtype warnings in several net, nio and security source files Summary: Also reviewed by Ulf.Zibis at gmx.de Reviewed-by: mcimadamore, alanb, dholmes ! make/sun/net/Makefile ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/security/Security.java ! src/share/classes/sun/nio/ch/Util.java From yuka.kamiya at oracle.com Wed Oct 26 13:18:19 2011 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Wed, 26 Oct 2011 13:18:19 +0000 Subject: hg: jdk8/tl/jdk: 7090046: Lots of invalid link in java.text.BreakIterator comments Message-ID: <20111026131829.155024712C@hg.openjdk.java.net> Changeset: 0d371f2911a1 Author: peytoia Date: 2011-10-26 22:16 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0d371f2911a1 7090046: Lots of invalid link in java.text.BreakIterator comments Reviewed-by: okutsu ! src/share/classes/java/text/BreakIterator.java From lana.steuck at oracle.com Wed Oct 26 19:52:54 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 26 Oct 2011 19:52:54 +0000 Subject: hg: jdk8/tl: 7 new changesets Message-ID: <20111026195254.8B64547139@hg.openjdk.java.net> Changeset: 0db7ae9f2b10 Author: katleman Date: 2011-09-22 16:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0db7ae9f2b10 Added tag jdk8-b06 for changeset 28cf2aec4dd7 ! .hgtags Changeset: cf76aa4189e4 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cf76aa4189e4 Added tag jdk8-b07 for changeset 0db7ae9f2b10 ! .hgtags Changeset: 2f1af0e3e8f7 Author: lana Date: 2011-09-26 14:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2f1af0e3e8f7 Merge Changeset: fb1bc13260d7 Author: lana Date: 2011-10-03 18:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/fb1bc13260d7 Merge Changeset: 8adb70647b5a Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8adb70647b5a Added tag jdk8-b08 for changeset fb1bc13260d7 ! .hgtags Changeset: a6c4c248e8fa Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a6c4c248e8fa Added tag jdk8-b09 for changeset 8adb70647b5a ! .hgtags Changeset: 1defbc57940a Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1defbc57940a Added tag jdk8-b10 for changeset a6c4c248e8fa ! .hgtags From lana.steuck at oracle.com Wed Oct 26 19:52:57 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 26 Oct 2011 19:52:57 +0000 Subject: hg: jdk8/tl/jaxp: 5 new changesets Message-ID: <20111026195257.9C6754713A@hg.openjdk.java.net> Changeset: c114306576dc Author: katleman Date: 2011-09-22 16:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/c114306576dc Added tag jdk8-b06 for changeset d7b8192e7277 ! .hgtags Changeset: de4794dd69c4 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/de4794dd69c4 Added tag jdk8-b07 for changeset c114306576dc ! .hgtags Changeset: 93554324c014 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/93554324c014 Added tag jdk8-b08 for changeset de4794dd69c4 ! .hgtags Changeset: d21a4d5141c0 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d21a4d5141c0 Added tag jdk8-b09 for changeset 93554324c014 ! .hgtags Changeset: d1b7a4f6dd20 Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d1b7a4f6dd20 Added tag jdk8-b10 for changeset d21a4d5141c0 ! .hgtags From lana.steuck at oracle.com Wed Oct 26 19:53:03 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 26 Oct 2011 19:53:03 +0000 Subject: hg: jdk8/tl/jaxws: 5 new changesets Message-ID: <20111026195303.DD0074713B@hg.openjdk.java.net> Changeset: 134b0debf7b0 Author: katleman Date: 2011-09-22 16:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/134b0debf7b0 Added tag jdk8-b06 for changeset acffff22a946 ! .hgtags Changeset: 1c9d4f59acf8 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/1c9d4f59acf8 Added tag jdk8-b07 for changeset 134b0debf7b0 ! .hgtags Changeset: 70172e57cf29 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/70172e57cf29 Added tag jdk8-b08 for changeset 1c9d4f59acf8 ! .hgtags Changeset: 8e7fdc8e3c75 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/8e7fdc8e3c75 Added tag jdk8-b09 for changeset 70172e57cf29 ! .hgtags Changeset: a12ab897a249 Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/a12ab897a249 Added tag jdk8-b10 for changeset 8e7fdc8e3c75 ! .hgtags From lana.steuck at oracle.com Wed Oct 26 19:52:54 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 26 Oct 2011 19:52:54 +0000 Subject: hg: jdk8/tl/corba: 5 new changesets Message-ID: <20111026195304.B18FC4713C@hg.openjdk.java.net> Changeset: 3d61f0856f34 Author: katleman Date: 2011-09-22 16:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/3d61f0856f34 Added tag jdk8-b06 for changeset 45c43dde7ba7 ! .hgtags Changeset: 0d52b1c87aa8 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/0d52b1c87aa8 Added tag jdk8-b07 for changeset 3d61f0856f34 ! .hgtags Changeset: a891732c1a83 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/a891732c1a83 Added tag jdk8-b08 for changeset 0d52b1c87aa8 ! .hgtags Changeset: cda87f7fefce Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cda87f7fefce Added tag jdk8-b09 for changeset a891732c1a83 ! .hgtags Changeset: 0199e4fef5cc Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/0199e4fef5cc Added tag jdk8-b10 for changeset cda87f7fefce ! .hgtags From lana.steuck at oracle.com Wed Oct 26 19:53:19 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 26 Oct 2011 19:53:19 +0000 Subject: hg: jdk8/tl/langtools: 11 new changesets Message-ID: <20111026195345.28F894713D@hg.openjdk.java.net> Changeset: 116980ecec5c Author: katleman Date: 2011-09-22 16:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/116980ecec5c Added tag jdk8-b06 for changeset d2422276f9da ! .hgtags Changeset: 9268bd271c6f Author: katleman Date: 2011-09-29 18:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9268bd271c6f Added tag jdk8-b07 for changeset 116980ecec5c ! .hgtags Changeset: 28573d605b01 Author: lana Date: 2011-09-26 14:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/28573d605b01 Merge - src/share/classes/com/sun/tools/javac/Launcher.java Changeset: e8acc2d6c32f Author: lana Date: 2011-10-03 18:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e8acc2d6c32f Merge - src/share/classes/com/sun/tools/javac/Launcher.java Changeset: b7a7e47c8d3d Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b7a7e47c8d3d Added tag jdk8-b08 for changeset e8acc2d6c32f ! .hgtags Changeset: 510d09ddc861 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/510d09ddc861 Added tag jdk8-b09 for changeset b7a7e47c8d3d ! .hgtags Changeset: 5010ffc61eda Author: lana Date: 2011-10-12 12:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5010ffc61eda Merge Changeset: f6c783e18bdf Author: lana Date: 2011-10-17 19:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f6c783e18bdf Merge Changeset: 4bf01f1c4e34 Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4bf01f1c4e34 Added tag jdk8-b10 for changeset f6c783e18bdf ! .hgtags Changeset: e52159ff8d0c Author: lana Date: 2011-10-25 10:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e52159ff8d0c Merge Changeset: 897b72b2751b Author: lana Date: 2011-10-26 12:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/897b72b2751b Merge - src/share/classes/com/sun/tools/javac/file/Paths.java From lana.steuck at oracle.com Wed Oct 26 19:53:43 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 26 Oct 2011 19:53:43 +0000 Subject: hg: jdk8/tl/hotspot: 114 new changesets Message-ID: <20111026195720.E89684713E@hg.openjdk.java.net> Changeset: 3f0cf875af83 Author: katleman Date: 2011-09-22 16:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3f0cf875af83 Added tag jdk8-b06 for changeset 0db80d8e77fc ! .hgtags Changeset: 0663e7617095 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0663e7617095 Added tag jdk8-b07 for changeset 3f0cf875af83 ! .hgtags Changeset: 5755e84e970f Author: jcoomes Date: 2011-09-02 15:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5755e84e970f Added tag hs22-b01 for changeset 0cc8a70952c3 ! .hgtags Changeset: 40c5e268d399 Author: jcoomes Date: 2011-09-02 15:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/40c5e268d399 Added tag hs22-b02 for changeset 7c29742c41b4 ! .hgtags Changeset: 52220701f19f Author: jcoomes Date: 2011-09-02 15:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/52220701f19f Added tag hs22-b03 for changeset 3a2fb61165df ! .hgtags Changeset: ce9bde819dcb Author: jcoomes Date: 2011-09-02 03:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ce9bde819dcb 7086589: bump the hs22 build number to 04 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 5c123cbeebbe Author: jcoomes Date: 2011-09-02 15:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5c123cbeebbe Added tag hs22-b04 for changeset ce9bde819dcb ! .hgtags Changeset: 3cd0157e1d4d Author: iveresov Date: 2011-08-25 02:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3cd0157e1d4d 7082969: NUMA interleaving Summary: Support interleaving on NUMA systems for collectors that don't have NUMA-awareness. Reviewed-by: iveresov, ysr Contributed-by: Tom Deneau ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: eeae91c9baba Author: johnc Date: 2011-08-29 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eeae91c9baba 7080389: G1: refactor marking code in evacuation pause copy closures Summary: Refactor code marking code in the evacuation pause copy closures so that an evacuated object is only marked by the thread that successfully copies it. Reviewed-by: stefank, brutisso, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp Changeset: 9447b2fb6fcf Author: iveresov Date: 2011-08-29 17:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9447b2fb6fcf 7082645: Hotspot doesn't compile on old linuxes after 7060836 Summary: Move syscall ids definitions into os_linux.cpp Reviewed-by: johnc ! src/os/linux/vm/os_linux.cpp Changeset: 4fe626cbf0bf Author: johnc Date: 2011-08-31 10:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4fe626cbf0bf 7066841: remove MacroAssembler::br_on_reg_cond() on sparc Summary: Remove the macro assembler routine br_on_reg_cond() and replace the remaining calls to that routine with an equivalent. Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: ae1b1788f63f Author: ysr Date: 2011-08-31 23:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ae1b1788f63f Merge Changeset: 4668545121b8 Author: jcoomes Date: 2011-09-02 21:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4668545121b8 Merge Changeset: ac8738449b6f Author: never Date: 2011-08-25 20:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ac8738449b6f 7082949: JSR 292: missing ResourceMark in methodOopDesc::make_invoke_method Reviewed-by: kvn, twisti ! src/share/vm/oops/methodOop.cpp + test/compiler/7082949/Test7082949.java Changeset: baf763f388e6 Author: kvn Date: 2011-08-26 08:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/baf763f388e6 7059037: Use BIS for zeroing on T4 Summary: Use BIS for zeroing new allocated big (2Kb and more) objects and arrays. Reviewed-by: never, twisti, ysr ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/copy_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp Changeset: 8805f8c1e23e Author: iveresov Date: 2011-08-27 00:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8805f8c1e23e 6591247: C2 cleans up the merge point too early during SplitIf Summary: Remove region self reference last Reviewed-by: kvn, never ! src/share/vm/opto/split_if.cpp Changeset: b27c72d69fd1 Author: twisti Date: 2011-08-29 05:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b27c72d69fd1 7083184: JSR 292: don't store context class argument with call site dependencies Reviewed-by: jrose, never ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/opto/callGenerator.cpp Changeset: 19241ae0d839 Author: never Date: 2011-08-30 00:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/19241ae0d839 7082263: Reflection::resolve_field/field_get/field_set are broken Reviewed-by: kvn, dholmes, stefank, coleenp ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/debug.make ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/jvmg.make - make/solaris/makefiles/mapfile-vers-nonproduct ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! src/share/vm/precompiled.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp - src/share/vm/runtime/reflectionCompat.hpp Changeset: b346f13112d8 Author: iveresov Date: 2011-08-30 19:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b346f13112d8 7085279: C1 overflows code buffer with VerifyOops and CompressedOops Summary: Increase the limit of code emitted per LIR instruction, increase the max size of the nmethod generated by C1 Reviewed-by: never, kvn, johnc ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_globals.hpp Changeset: de847cac9235 Author: twisti Date: 2011-08-31 01:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de847cac9235 7078382: JSR 292: don't count method handle adapters against inlining budgets Reviewed-by: kvn, never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/opto/bytecodeInfo.cpp Changeset: a64d352d1118 Author: kvn Date: 2011-08-31 09:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a64d352d1118 7085137: -XX:+VerifyOops is broken Summary: Replace set() with patchable_set() to generate 8 instructions always. Reviewed-by: iveresov, never, roland ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/sparc.ad Changeset: c124e2e7463e Author: never Date: 2011-08-31 16:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c124e2e7463e 7083786: dead various dead chunks of code Reviewed-by: iveresov, kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.hpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/ci/ciConstant.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: a32de5085326 Author: twisti Date: 2011-09-01 01:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a32de5085326 7079673: JSR 292: C1 should inline bytecoded method handle adapters Reviewed-by: never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/parse.hpp Changeset: aa67216400d3 Author: twisti Date: 2011-09-02 00:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aa67216400d3 7085404: JSR 292: VolatileCallSites should have push notification too Reviewed-by: never, kvn ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/prims/unsafe.cpp Changeset: 11a4af030e4b Author: twisti Date: 2011-09-02 04:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/11a4af030e4b 7071709: JSR 292: switchpoint invalidation should be pushed not pulled Reviewed-by: never ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parse3.cpp Changeset: 2f9b79ddb05c Author: kvn Date: 2011-09-02 12:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2f9b79ddb05c 7039731: arraycopy could use prefetch on SPARC Summary: Use BIS and prefetch in arraycopy stubs for Sparc (BIS for T4 only). Reviewed-by: never, iveresov ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/runtime/globals.hpp Changeset: 2090c623107e Author: never Date: 2011-09-02 22:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2090c623107e 7016881: JSR 292: JDI: sun.jvm.hotspot.utilities.AssertionFailure: index out of bounds Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java Changeset: c26de9aef2ed Author: never Date: 2011-09-02 20:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c26de9aef2ed 7071307: MethodHandle bimorphic inlining should consider the frequency Reviewed-by: twisti, roland, kvn, iveresov ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/ci/ciCallProfile.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciObject.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: 7ffacbb338d4 Author: never Date: 2011-09-03 09:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ffacbb338d4 Merge Changeset: 7b5c767f229c Author: kvn Date: 2011-09-03 14:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7b5c767f229c 7086560: 7085404 changes broke VM with -XX:-EnableInvokeDynamic Summary: Add check that ciEnv::_CallSite_klass is initialized. Reviewed-by: jrose ! src/share/vm/ci/ciField.hpp Changeset: 7588156f5cf9 Author: never Date: 2011-09-05 17:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7588156f5cf9 7051798: SA-JDI: NPE in Frame.addressOfStackSlot(Frame.java:244) Reviewed-by: kvn ! agent/src/share/classes/sun/jvm/hotspot/HSDB.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java + agent/src/share/classes/sun/jvm/hotspot/code/MethodHandlesAdapterBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/code/PCDesc.java ! agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/RuntimeStub.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/OopMapSet.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/ReferenceTypeImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/StackFrameImpl.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/CompiledVFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Frame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/StackValue.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/linux_amd64/LinuxAMD64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/solaris_amd64/SolarisAMD64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCFrame.java + agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/win32_amd64/Win32AMD64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java + agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/code/pcDesc.cpp ! src/share/vm/code/pcDesc.hpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c2d3caa64b3e Author: roland Date: 2011-09-07 09:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c2d3caa64b3e 7086394: c2/arm: enable UseFPUForSpilling Summary: ARM has instructions to move data directly between the fpu and integer registers. Reviewed-by: kvn, never ! src/share/vm/opto/matcher.cpp Changeset: d968f546734e Author: iveresov Date: 2011-09-07 11:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d968f546734e Merge - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java - make/solaris/makefiles/mapfile-vers-nonproduct ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/runtime/globals.hpp - src/share/vm/runtime/reflectionCompat.hpp Changeset: 2fecca53a2c6 Author: roland Date: 2011-09-07 14:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2fecca53a2c6 7085012: ARM: com/sun/jdi/PopSynchronousTest.java still fails Summary: InterpreterRuntime::popframe_move_outgoing_args() is required for the ARM interpreter. Reviewed-by: kvn, twisti ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp Changeset: 5596e125fe4f Author: rottenha Date: 2011-09-08 06:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5596e125fe4f Merge ! src/share/vm/interpreter/interpreterRuntime.cpp Changeset: 27702f012017 Author: iveresov Date: 2011-09-06 21:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/27702f012017 7087583: Hotspot fails to allocate heap with mmap(MAP_HUGETLB) Summary: Try using small pages when transparent huge pages allocation fails Reviewed-by: ysr ! src/os/linux/vm/os_linux.cpp Changeset: 20213c8a3c40 Author: tonyp Date: 2011-09-07 12:21 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/20213c8a3c40 7050392: G1: Introduce flag to generate a log of the G1 ergonomic decisions Summary: It introduces ergonomic decision logging in G1 for the following heuristics: heap sizing, collection set construction, concurrent cycle initiation, and partially-young GC start/end. The code has a bit of refactoring in a few places to make the decision logging possible. It also replaces alternative ad-hoc logging that we have under different parameters and switches (G1_DEBUG, G1PolicyVerbose). Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp + src/share/vm/gc_implementation/g1/g1ErgoVerbose.cpp + src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp Changeset: c2bf0120ee5d Author: stefank Date: 2011-09-01 16:18 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c2bf0120ee5d 7085906: Replace the permgen allocated sentinelRef with a self-looped end Summary: Remove the sentinelRef and let the last Reference in a discovered chain point back to itself. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp Changeset: 05550041d664 Author: ysr Date: 2011-09-07 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/05550041d664 Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: eca1193ca245 Author: ysr Date: 2011-09-07 13:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eca1193ca245 4965777: GC changes to support use of discovered field for pending references Summary: If and when the reference handler thread is able to use the discovered field to link reference objects in its pending list, so will GC. In that case, GC will scan through this field once a reference object has been placed on the pending list, but not scan that field before that stage, as the field is used by the concurrent GC thread to link discovered objects. When ReferenceHandleR thread does not use the discovered field for the purpose of linking the elements in the pending list, as would be the case in older JDKs, the JVM will fall back to the old behaviour of using the next field for that purpose. Reviewed-by: jcoomes, mchung, stefank ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp Changeset: a6128a8ed624 Author: iveresov Date: 2011-09-07 18:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a6128a8ed624 7086226: UseNUMA fails on old versions of windows Summary: Return correct answers from os::numa_*() for UMA machines or if NUMA API is not supported Reviewed-by: johnc ! src/os/windows/vm/os_windows.cpp Changeset: 4f41766176cf Author: tonyp Date: 2011-09-08 05:16 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4f41766176cf 7084509: G1: fix inconsistencies and mistakes in the young list target length calculations Summary: Fixed inconsistencies and mistakes in the young list target length calculations so that a) the calculated target length is optimal (before, it was not), b) other parameters like max survivor size and max gc locker eden expansion are always consistent with the calculated target length (before, they were not always), and c) the resulting target length was always bound by desired min and max values (before, it was not). Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! 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: af2ab04e0038 Author: brutisso Date: 2011-09-08 16:29 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/af2ab04e0038 6929868: G1: introduce min / max young gen size bounds Summary: Make G1 handle young gen size command line flags more consistently Reviewed-by: tonyp, jwilhelm ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 3bddbf0f57d6 Author: tonyp Date: 2011-09-09 05:20 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3bddbf0f57d6 7087717: G1: make the G1PrintRegionLivenessInfo parameter diagnostic Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: e984655be425 Author: stefank Date: 2011-09-09 14:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e984655be425 Merge ! src/share/vm/prims/jvm.h Changeset: 79f9a3ed607a Author: jcoomes Date: 2011-09-09 16:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/79f9a3ed607a Merge ! .hgtags - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java - make/solaris/makefiles/mapfile-vers-nonproduct - src/share/vm/runtime/reflectionCompat.hpp Changeset: 513a84dd0f8b Author: jcoomes Date: 2011-09-09 16:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/513a84dd0f8b 7088991: Bump ths hs22 build number to 05 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 140317da459a Author: jcoomes Date: 2011-09-09 16:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/140317da459a Added tag hs22-b05 for changeset 513a84dd0f8b ! .hgtags Changeset: f1b4e0e0bdad Author: tonyp Date: 2011-09-13 12:40 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f1b4e0e0bdad 7089625: G1: policy for how many old regions to add to the CSet (when young gen is fixed) is broken Summary: When refactoring the code for a previous fix, a condition was not correctly negated which prevents the G1 policy from adding the correct number of old regions to the CSet when the young gen size is fixed. The changeset also fixes a small syntactical issue in g1ErgoVerbose.hpp which is causing compiler warnings. Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp Changeset: 0a63380c8ac8 Author: iveresov Date: 2011-09-13 16:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0a63380c8ac8 7090069: Java launcher hangs in infinite loop on windows when UseNUMA[Interleaving] is specified Summary: Fix _numa_used_node_list array size specification Reviewed-by: kvn, johnc, jmasa, ysr ! src/os/windows/vm/os_windows.cpp Changeset: f94227b6117b Author: kvn Date: 2011-09-13 20:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f94227b6117b 7090259: Fix hotspot sources to build with old compilers Summary: Fixed warnings which prevent building VM with old compilers. Reviewed-by: never ! make/solaris/makefiles/sparcWorks.make ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/opto/block.cpp Changeset: da6a29fb0da5 Author: kvn Date: 2011-09-07 12:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/da6a29fb0da5 7054211: No loop unrolling done in jdk7b144 for a test update() while loop Summary: restore unrolling code for CaffeineMark. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp Changeset: 5432047c7db7 Author: bdelsart Date: 2011-09-08 10:12 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5432047c7db7 7087445: Improve platform independence of JSR292 shared code Summary: changes necessary for some JSR292 ports Reviewed-by: jrose, dholmes ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/zero/vm/frame_zero.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/frame.hpp Changeset: b0efc7ee3b31 Author: twisti Date: 2011-09-08 05:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b0efc7ee3b31 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods Reviewed-by: jrose, never ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/oops/klassOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/prims/methodHandles.cpp Changeset: fdcb1e828d53 Author: kvn Date: 2011-09-08 12:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fdcb1e828d53 7087947: Add regression test for 7068051 Summary: Add regression test. Reviewed-by: never + test/compiler/7068051/Test7068051.java + test/compiler/7068051/Test7068051.sh Changeset: 8f47d8870d9a Author: roland Date: 2011-09-08 09:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8f47d8870d9a 7087453: PhaseChaitin::yank_if_dead() should handle MachTemp inputs Summary: PhaseChaitin::yank_if_dead() should be able to handle MachTemp inputs as a special case and yank them. Reviewed-by: never, kvn ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/postaloc.cpp Changeset: 5257f8e66b40 Author: iveresov Date: 2011-09-09 12:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5257f8e66b40 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 2c24ef16533d Author: kvn Date: 2011-09-09 13:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c24ef16533d 7035946: Up to 15% regression on JDK 7 b136 vs b135 on specjvm2008.crypto.rsa on x64 Summary: Revert changes which caused regression. Reviewed-by: never ! src/share/vm/opto/loopnode.cpp Changeset: c565834fb592 Author: never Date: 2011-09-10 00:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c565834fb592 7088020: SEGV in JNIHandleBlock::release_block Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/stubGenerator_sparc.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/zero/vm/stubGenerator_zero.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp + test/compiler/7088020/Test7088020.java Changeset: e6b1331a51d2 Author: never Date: 2011-09-10 17:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e6b1331a51d2 7086585: make Java field injection more flexible Reviewed-by: jrose, twisti, kvn, coleenp ! agent/src/share/classes/sun/jvm/hotspot/oops/Field.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/java_lang_Class.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/test/jdi/sasanity.sh ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/cpCacheOop.cpp + src/share/vm/oops/fieldInfo.hpp + src/share/vm/oops/fieldStreams.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/accessFlags.hpp Changeset: f6f3bb0ee072 Author: never Date: 2011-09-11 14:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f6f3bb0ee072 7088955: add C2 IR support to the SA Reviewed-by: kvn ! agent/make/Makefile ! agent/make/saenv.sh ! agent/make/saenv64.sh ! agent/src/os/solaris/Makefile - agent/src/os/solaris/dbx/Makefile - agent/src/os/solaris/dbx/README - agent/src/os/solaris/dbx/README-commands.txt - agent/src/os/solaris/dbx/helloWorld.cpp - agent/src/os/solaris/dbx/proc_service_2.h - agent/src/os/solaris/dbx/shell_imp.h - agent/src/os/solaris/dbx/svc_agent_dbx.cpp - agent/src/os/solaris/dbx/svc_agent_dbx.hpp - agent/src/os/win32/BasicList.hpp - agent/src/os/win32/Buffer.cpp - agent/src/os/win32/Buffer.hpp - agent/src/os/win32/Dispatcher.cpp - agent/src/os/win32/Dispatcher.hpp - agent/src/os/win32/Handler.hpp - agent/src/os/win32/IOBuf.cpp - agent/src/os/win32/IOBuf.hpp - agent/src/os/win32/LockableList.hpp - agent/src/os/win32/Makefile - agent/src/os/win32/Message.hpp - agent/src/os/win32/Monitor.cpp - agent/src/os/win32/Monitor.hpp - agent/src/os/win32/README-commands.txt - agent/src/os/win32/README.txt - agent/src/os/win32/Reaper.cpp - agent/src/os/win32/Reaper.hpp - agent/src/os/win32/SwDbgSrv.cpp - agent/src/os/win32/SwDbgSrv.dsp - agent/src/os/win32/SwDbgSrv.dsw - agent/src/os/win32/SwDbgSub.cpp - agent/src/os/win32/SwDbgSub.dsp - agent/src/os/win32/initWinsock.cpp - agent/src/os/win32/initWinsock.hpp - agent/src/os/win32/ioUtils.cpp - agent/src/os/win32/ioUtils.hpp - agent/src/os/win32/isNT4.cpp - agent/src/os/win32/isNT4.hpp - agent/src/os/win32/libInfo.cpp - agent/src/os/win32/libInfo.hpp - agent/src/os/win32/nt4internals.cpp - agent/src/os/win32/nt4internals.hpp - agent/src/os/win32/ports.h - agent/src/os/win32/procList.cpp - agent/src/os/win32/procList.hpp - agent/src/os/win32/serverLists.cpp - agent/src/os/win32/serverLists.hpp - agent/src/os/win32/toolHelp.cpp - agent/src/os/win32/toolHelp.hpp ! agent/src/share/classes/sun/jvm/hotspot/CLHSDB.java ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/DebugServer.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciConstant.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciField.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciInstance.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodData.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciObject.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciObjectFactory.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciReceiverTypeData.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciSymbol.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciType.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciVirtualCallData.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java + agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/AddressException.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxAddress.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxOopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/AddressDataSource.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/DLL.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestHelloWorld.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Address.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugInfoBuilder.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Debugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32DebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntry.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntryConstants.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32OopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/SADebugServer.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/VirtualMachineImpl.java + agent/src/share/classes/sun/jvm/hotspot/oops/ArrayData.java + agent/src/share/classes/sun/jvm/hotspot/oops/BitData.java + agent/src/share/classes/sun/jvm/hotspot/oops/BranchData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/CIntField.java + agent/src/share/classes/sun/jvm/hotspot/oops/CounterData.java + agent/src/share/classes/sun/jvm/hotspot/oops/DataLayout.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Field.java ! agent/src/share/classes/sun/jvm/hotspot/oops/FieldType.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java + agent/src/share/classes/sun/jvm/hotspot/oops/JumpData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java + agent/src/share/classes/sun/jvm/hotspot/oops/MultiBranchData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java + agent/src/share/classes/sun/jvm/hotspot/oops/ProfileData.java + agent/src/share/classes/sun/jvm/hotspot/oops/ReceiverTypeData.java + agent/src/share/classes/sun/jvm/hotspot/oops/RetData.java + agent/src/share/classes/sun/jvm/hotspot/oops/VirtualCallData.java + agent/src/share/classes/sun/jvm/hotspot/opto/Block.java + agent/src/share/classes/sun/jvm/hotspot/opto/Block_Array.java + agent/src/share/classes/sun/jvm/hotspot/opto/Block_List.java + agent/src/share/classes/sun/jvm/hotspot/opto/CallDynamicJavaNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/CallJavaNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/CallNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/CallRuntimeNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/CallStaticJavaNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/Compile.java + agent/src/share/classes/sun/jvm/hotspot/opto/HaltNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/InlineTree.java + agent/src/share/classes/sun/jvm/hotspot/opto/JVMState.java + agent/src/share/classes/sun/jvm/hotspot/opto/LoopNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachCallJavaNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachCallNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachCallRuntimeNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachCallStaticJavaNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachIfNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachReturnNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachSafePointNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MultiNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/Node.java + agent/src/share/classes/sun/jvm/hotspot/opto/Node_Array.java + agent/src/share/classes/sun/jvm/hotspot/opto/Node_List.java + agent/src/share/classes/sun/jvm/hotspot/opto/Phase.java + agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java + agent/src/share/classes/sun/jvm/hotspot/opto/PhaseRegAlloc.java + agent/src/share/classes/sun/jvm/hotspot/opto/PhiNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/ProjNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/RegionNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/RootNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/SafePointNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/TypeNode.java + agent/src/share/classes/sun/jvm/hotspot/prims/JvmtiExport.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/CompilerThread.java + agent/src/share/classes/sun/jvm/hotspot/runtime/InstanceConstructor.java + agent/src/share/classes/sun/jvm/hotspot/runtime/StaticBaseConstructor.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java + agent/src/share/classes/sun/jvm/hotspot/runtime/VirtualBaseConstructor.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VirtualConstructor.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/win32_amd64/Win32AMD64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/win32_x86/Win32X86JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java ! agent/src/share/classes/sun/jvm/hotspot/types/TypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/ui/CommandProcessorPanel.java + agent/src/share/classes/sun/jvm/hotspot/utilities/GenericGrowableArray.java + agent/src/share/classes/sun/jvm/hotspot/utilities/GrowableArray.java ! make/sa.files ! src/share/vm/ci/ciArrayKlass.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciConstant.hpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/optoreg.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/regalloc.hpp ! src/share/vm/opto/type.hpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/vframeArray.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/growableArray.hpp Changeset: ab577c97a5f3 Author: never Date: 2011-09-12 13:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ab577c97a5f3 7089709: type "jushort" not found Reviewed-by: kvn, twisti ! src/share/vm/runtime/vmStructs.cpp Changeset: 2209834ccb59 Author: kvn Date: 2011-09-13 11:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2209834ccb59 7089632: assert(machtmp->outcnt() == 1) failed: expected for a MachTemp Summary: Replace assert with check to delete MachTemp nodes only when they are really dead. Reviewed-by: never ! src/share/vm/opto/postaloc.cpp Changeset: 10ee2b297ccd Author: bdelsart Date: 2011-09-14 10:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/10ee2b297ccd 7057978: improve robustness of c1 ARM back-end wrt non encodable constants Summary: ARM only, avoid assertion failures for huge constants generated by C1 shared code Reviewed-by: never, vladidan ! src/share/vm/c1/c1_LIR.cpp Changeset: 393f4b789fd0 Author: bdelsart Date: 2011-09-14 16:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/393f4b789fd0 7077806: ARM: java.lang.InternalError: bound subword value does not fit into the subword type Summary: shared fix necessary for ARM/PPC Reviewed-by: twisti, roland ! src/share/vm/prims/methodHandles.hpp Changeset: 35c656d0b685 Author: never Date: 2011-09-14 13:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/35c656d0b685 7090654: nightly failures after 7086585 Reviewed-by: kvn ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp Changeset: 8ed53447f690 Author: iveresov Date: 2011-09-15 12:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8ed53447f690 Merge - agent/src/os/solaris/dbx/Makefile - agent/src/os/solaris/dbx/README - agent/src/os/solaris/dbx/README-commands.txt - agent/src/os/solaris/dbx/helloWorld.cpp - agent/src/os/solaris/dbx/proc_service_2.h - agent/src/os/solaris/dbx/shell_imp.h - agent/src/os/solaris/dbx/svc_agent_dbx.cpp - agent/src/os/solaris/dbx/svc_agent_dbx.hpp - agent/src/os/win32/BasicList.hpp - agent/src/os/win32/Buffer.cpp - agent/src/os/win32/Buffer.hpp - agent/src/os/win32/Dispatcher.cpp - agent/src/os/win32/Dispatcher.hpp - agent/src/os/win32/Handler.hpp - agent/src/os/win32/IOBuf.cpp - agent/src/os/win32/IOBuf.hpp - agent/src/os/win32/LockableList.hpp - agent/src/os/win32/Makefile - agent/src/os/win32/Message.hpp - agent/src/os/win32/Monitor.cpp - agent/src/os/win32/Monitor.hpp - agent/src/os/win32/README-commands.txt - agent/src/os/win32/README.txt - agent/src/os/win32/Reaper.cpp - agent/src/os/win32/Reaper.hpp - agent/src/os/win32/SwDbgSrv.cpp - agent/src/os/win32/SwDbgSrv.dsp - agent/src/os/win32/SwDbgSrv.dsw - agent/src/os/win32/SwDbgSub.cpp - agent/src/os/win32/SwDbgSub.dsp - agent/src/os/win32/initWinsock.cpp - agent/src/os/win32/initWinsock.hpp - agent/src/os/win32/ioUtils.cpp - agent/src/os/win32/ioUtils.hpp - agent/src/os/win32/isNT4.cpp - agent/src/os/win32/isNT4.hpp - agent/src/os/win32/libInfo.cpp - agent/src/os/win32/libInfo.hpp - agent/src/os/win32/nt4internals.cpp - agent/src/os/win32/nt4internals.hpp - agent/src/os/win32/ports.h - agent/src/os/win32/procList.cpp - agent/src/os/win32/procList.hpp - agent/src/os/win32/serverLists.cpp - agent/src/os/win32/serverLists.hpp - agent/src/os/win32/toolHelp.cpp - agent/src/os/win32/toolHelp.hpp - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxAddress.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxOopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/AddressDataSource.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/DLL.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestHelloWorld.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Address.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugInfoBuilder.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Debugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32DebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntry.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntryConstants.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32OopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32ThreadContext.java ! src/share/vm/classfile/javaClasses.cpp Changeset: 558f525a6ebe Author: jcoomes Date: 2011-09-15 19:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/558f525a6ebe Merge ! .hgtags - agent/src/os/solaris/dbx/Makefile - agent/src/os/solaris/dbx/README - agent/src/os/solaris/dbx/README-commands.txt - agent/src/os/solaris/dbx/helloWorld.cpp - agent/src/os/solaris/dbx/proc_service_2.h - agent/src/os/solaris/dbx/shell_imp.h - agent/src/os/solaris/dbx/svc_agent_dbx.cpp - agent/src/os/solaris/dbx/svc_agent_dbx.hpp - agent/src/os/win32/BasicList.hpp - agent/src/os/win32/Buffer.cpp - agent/src/os/win32/Buffer.hpp - agent/src/os/win32/Dispatcher.cpp - agent/src/os/win32/Dispatcher.hpp - agent/src/os/win32/Handler.hpp - agent/src/os/win32/IOBuf.cpp - agent/src/os/win32/IOBuf.hpp - agent/src/os/win32/LockableList.hpp - agent/src/os/win32/Makefile - agent/src/os/win32/Message.hpp - agent/src/os/win32/Monitor.cpp - agent/src/os/win32/Monitor.hpp - agent/src/os/win32/README-commands.txt - agent/src/os/win32/README.txt - agent/src/os/win32/Reaper.cpp - agent/src/os/win32/Reaper.hpp - agent/src/os/win32/SwDbgSrv.cpp - agent/src/os/win32/SwDbgSrv.dsp - agent/src/os/win32/SwDbgSrv.dsw - agent/src/os/win32/SwDbgSub.cpp - agent/src/os/win32/SwDbgSub.dsp - agent/src/os/win32/initWinsock.cpp - agent/src/os/win32/initWinsock.hpp - agent/src/os/win32/ioUtils.cpp - agent/src/os/win32/ioUtils.hpp - agent/src/os/win32/isNT4.cpp - agent/src/os/win32/isNT4.hpp - agent/src/os/win32/libInfo.cpp - agent/src/os/win32/libInfo.hpp - agent/src/os/win32/nt4internals.cpp - agent/src/os/win32/nt4internals.hpp - agent/src/os/win32/ports.h - agent/src/os/win32/procList.cpp - agent/src/os/win32/procList.hpp - agent/src/os/win32/serverLists.cpp - agent/src/os/win32/serverLists.hpp - agent/src/os/win32/toolHelp.cpp - agent/src/os/win32/toolHelp.hpp - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxAddress.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxOopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/AddressDataSource.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/DLL.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestHelloWorld.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Address.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugInfoBuilder.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Debugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32DebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntry.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntryConstants.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32OopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java - make/solaris/makefiles/mapfile-vers-nonproduct - src/share/vm/runtime/reflectionCompat.hpp Changeset: 8ab2f4108d20 Author: jcoomes Date: 2011-09-15 20:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8ab2f4108d20 7091294: disable quicksort tests Reviewed-by: jmasa, ysr, kvn ! src/share/vm/utilities/quickSort.cpp Changeset: 650d15d8f372 Author: jcoomes Date: 2011-09-15 20:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/650d15d8f372 7091255: Bump the hs22 build number to 06 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 5a3c2bc614ca Author: jcoomes Date: 2011-09-15 20:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5a3c2bc614ca Added tag hs22-b06 for changeset 650d15d8f372 ! .hgtags Changeset: 77e1a9153757 Author: jcoomes Date: 2011-09-16 21:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/77e1a9153757 7091545: hs23 - set hotspot version & build number Reviewed-by: tonyp, never, phh, jmasa ! make/hotspot_version Changeset: da0999c4b733 Author: dcubed Date: 2011-09-16 16:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/da0999c4b733 7071904: 4/4 HotSpot: Full Debug Symbols Summary: Add support for .debuginfo files for HSX libraries. Reviewed-by: poonam, dholmes, never ! make/Makefile ! make/linux/Makefile ! make/linux/makefiles/build_vm_def.sh ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/product.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/vm.make ! make/solaris/Makefile + make/solaris/makefiles/build_vm_def.sh ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/mapfile-vers ! make/solaris/makefiles/product.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make Changeset: 86cbe939f0c7 Author: dcubed Date: 2011-09-19 12:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/86cbe939f0c7 Merge Changeset: 3607aac85aa9 Author: kevinw Date: 2011-09-22 16:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3607aac85aa9 7051189: Need to suppress info message if -xcheck:jni used with libjsig.so Reviewed-by: coleenp, minqi ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp + test/runtime/7051189/Xchecksig.sh Changeset: 5cceda753a4a Author: iveresov Date: 2011-09-19 15:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5cceda753a4a 7091764: Tiered: enable aastore profiling Summary: Turn on aastore profiling Reviewed-by: jrose, twisti ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp Changeset: 075ea0ed9e7c Author: kvn Date: 2011-09-20 08:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/075ea0ed9e7c 7081842: assert(Compile::current()->unique() < (uint)MaxNodeLimit) failed: Node limit exceeded Summary: Add missing node limit check in IGVN optimizer Reviewed-by: iveresov, never ! make/linux/build.sh ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Phase.java ! src/share/vm/opto/phaseX.cpp Changeset: eda6988c0d81 Author: never Date: 2011-09-20 23:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eda6988c0d81 7092236: java/util/EnumSet/EnumSetBash.java fails Reviewed-by: kvn, twisti, jrose ! src/share/vm/ci/ciEnv.cpp Changeset: f08d439fab8c Author: never Date: 2011-09-25 16:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f08d439fab8c 7089790: integrate bsd-port changes Reviewed-by: kvn, twisti, jrose Contributed-by: Kurt Miller , Greg Lewis , Jung-uk Kim , Christos Zoulas , Landon Fuller , The FreeBSD Foundation , Michael Franz , Roger Hoover , Alexander Strange ! agent/make/Makefile + agent/src/os/bsd/BsdDebuggerLocal.c + agent/src/os/bsd/Makefile + agent/src/os/bsd/StubDebuggerLocal.c + agent/src/os/bsd/elfmacros.h + agent/src/os/bsd/libproc.h + agent/src/os/bsd/libproc_impl.c + agent/src/os/bsd/libproc_impl.h + agent/src/os/bsd/mapfile + agent/src/os/bsd/ps_core.c + agent/src/os/bsd/ps_proc.c + agent/src/os/bsd/salibelf.c + agent/src/os/bsd/salibelf.h + agent/src/os/bsd/symtab.c + agent/src/os/bsd/symtab.h + agent/src/os/bsd/test.c + agent/src/share/classes/sun/jvm/hotspot/BsdVtblAccess.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdCDebugger.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdOopHandle.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThread.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThreadContextFactory.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/SharedObject.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/amd64/BsdAMD64CFrame.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/amd64/BsdAMD64ThreadContext.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/x86/BsdX86CFrame.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/x86/BsdX86ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java + agent/src/share/classes/sun/jvm/hotspot/runtime/bsd/BsdSignals.java + agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_amd64/BsdAMD64JavaThreadPDAccess.java + agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_x86/BsdSignals.java + agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_x86/BsdX86JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! make/Makefile + make/bsd/Makefile + make/bsd/README + make/bsd/adlc_updater + make/bsd/build.sh + make/bsd/makefiles/adjust-mflags.sh + make/bsd/makefiles/adlc.make + make/bsd/makefiles/amd64.make + make/bsd/makefiles/arm.make + make/bsd/makefiles/build_vm_def.sh + make/bsd/makefiles/buildtree.make + make/bsd/makefiles/compiler1.make + make/bsd/makefiles/compiler2.make + make/bsd/makefiles/core.make + make/bsd/makefiles/cscope.make + make/bsd/makefiles/debug.make + make/bsd/makefiles/defs.make + make/bsd/makefiles/dtrace.make + make/bsd/makefiles/fastdebug.make + make/bsd/makefiles/gcc.make + make/bsd/makefiles/hp.make + make/bsd/makefiles/hp1.make + make/bsd/makefiles/i486.make + make/bsd/makefiles/ia64.make + make/bsd/makefiles/jsig.make + make/bsd/makefiles/jvmg.make + make/bsd/makefiles/jvmti.make + make/bsd/makefiles/launcher.make + make/bsd/makefiles/mapfile-vers-debug + make/bsd/makefiles/mapfile-vers-jsig + make/bsd/makefiles/mapfile-vers-product + make/bsd/makefiles/optimized.make + make/bsd/makefiles/ppc.make + make/bsd/makefiles/product.make + make/bsd/makefiles/profiled.make + make/bsd/makefiles/rules.make + make/bsd/makefiles/sa.make + make/bsd/makefiles/saproc.make + make/bsd/makefiles/shark.make + make/bsd/makefiles/sparc.make + make/bsd/makefiles/sparcWorks.make + make/bsd/makefiles/sparcv9.make + make/bsd/makefiles/tiered.make + make/bsd/makefiles/top.make + make/bsd/makefiles/vm.make + make/bsd/makefiles/zero.make + make/bsd/makefiles/zeroshark.make + make/bsd/platform_amd64 + make/bsd/platform_amd64.suncc + make/bsd/platform_i486 + make/bsd/platform_i486.suncc + make/bsd/platform_ia64 + make/bsd/platform_sparc + make/bsd/platform_sparcv9 + make/bsd/platform_zero.in ! make/cscope.make ! make/defs.make ! make/linux/makefiles/arm.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/ppc.make ! make/sa.files ! make/solaris/makefiles/defs.make ! make/windows/makefiles/defs.make ! src/cpu/x86/vm/bytes_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/copy_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/jni_x86.h ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/zero/vm/bytes_zero.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/cpu/zero/vm/interp_masm_zero.cpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/cpu/zero/vm/stubRoutines_zero.cpp ! src/cpu/zero/vm/vm_version_zero.cpp + src/os/bsd/vm/attachListener_bsd.cpp + src/os/bsd/vm/c1_globals_bsd.hpp + src/os/bsd/vm/c2_globals_bsd.hpp + src/os/bsd/vm/chaitin_bsd.cpp + src/os/bsd/vm/decoder_bsd.cpp + src/os/bsd/vm/dtraceJSDT_bsd.cpp + src/os/bsd/vm/globals_bsd.hpp + src/os/bsd/vm/interfaceSupport_bsd.hpp + src/os/bsd/vm/jsig.c + src/os/bsd/vm/jvm_bsd.cpp + src/os/bsd/vm/jvm_bsd.h + src/os/bsd/vm/mutex_bsd.cpp + src/os/bsd/vm/mutex_bsd.inline.hpp + src/os/bsd/vm/osThread_bsd.cpp + src/os/bsd/vm/osThread_bsd.hpp + src/os/bsd/vm/os_bsd.cpp + src/os/bsd/vm/os_bsd.hpp + src/os/bsd/vm/os_bsd.inline.hpp + src/os/bsd/vm/os_share_bsd.hpp + src/os/bsd/vm/perfMemory_bsd.cpp + src/os/bsd/vm/stubRoutines_bsd.cpp + src/os/bsd/vm/threadCritical_bsd.cpp + src/os/bsd/vm/thread_bsd.inline.hpp + src/os/bsd/vm/vmError_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/posix/launcher/java_md.c ! src/os/posix/launcher/launcher.script + src/os_cpu/bsd_x86/vm/assembler_bsd_x86.cpp + src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/bsd_x86_32.ad + src/os_cpu/bsd_x86/vm/bsd_x86_32.s + src/os_cpu/bsd_x86/vm/bsd_x86_64.ad + src/os_cpu/bsd_x86/vm/bsd_x86_64.s + src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/copy_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp + src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/prefetch_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/threadLS_bsd_x86.cpp + src/os_cpu/bsd_x86/vm/threadLS_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp + src/os_cpu/bsd_x86/vm/thread_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/vm_version_bsd_x86.cpp + src/os_cpu/bsd_zero/vm/assembler_bsd_zero.cpp + src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp + src/os_cpu/bsd_zero/vm/bytes_bsd_zero.inline.hpp + src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp + src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp + src/os_cpu/bsd_zero/vm/os_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/prefetch_bsd_zero.inline.hpp + src/os_cpu/bsd_zero/vm/threadLS_bsd_zero.cpp + src/os_cpu/bsd_zero/vm/threadLS_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/thread_bsd_zero.cpp + src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/vmStructs_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/vm_version_bsd_zero.cpp ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp ! src/share/vm/adlc/adlc.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/resourceArea.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/markOop.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oopsHierarchy.cpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/javaFrameAnchor.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/osThread.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/threadLocalStorage.cpp ! src/share/vm/runtime/threadLocalStorage.hpp ! src/share/vm/runtime/timer.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/accessFlags.cpp ! src/share/vm/utilities/array.cpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.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/events.cpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/growableArray.cpp ! src/share/vm/utilities/histogram.hpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/preserveException.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/workgroup.hpp ! test/Makefile ! test/jprt.config ! test/runtime/6929067/Test6929067.sh Changeset: a92cdbac8b9e Author: kvn Date: 2011-09-26 10:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a92cdbac8b9e 7081933: Use zeroing elimination optimization for large array Summary: Don't zero new typeArray during runtime call if the allocation is followed by arraycopy into it. Reviewed-by: twisti ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.hpp ! 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/runtime.cpp ! src/share/vm/opto/runtime.hpp Changeset: cb315dc80374 Author: never Date: 2011-09-29 09:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cb315dc80374 7092278: "jmap -finalizerinfo" throws "sun.jvm.hotspot.utilities.AssertionFailure: invalid cp index 0 137" Reviewed-by: kvn ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java + agent/src/share/classes/sun/jvm/hotspot/runtime/vmSymbols.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 098acdf97f09 Author: never Date: 2011-09-29 13:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/098acdf97f09 7096016: SA build still produces "arg list too long" errors Reviewed-by: kvn, never Contributed-by: volker.simonis at gmail.com ! make/linux/makefiles/sa.make ! make/sa.files ! make/solaris/makefiles/sa.make ! make/windows/makefiles/sa.make Changeset: dc45ae774613 Author: iveresov Date: 2011-09-29 23:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dc45ae774613 7096639: Tiered: Incorrect counter overflow handling for inlined methods Summary: Enable invocation events for inlinees Reviewed-by: kvn ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/runtime/globals.hpp Changeset: ae839d1e7d4c Author: roland Date: 2011-09-30 13:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ae839d1e7d4c 7096010: c2: running with +PrintOptoAssembly crashes the VM when $constanttablebase is used Summary: ADLC generates code to prepare the register string to be printed in a char array but then calls print without the char array as an argument. Reviewed-by: never ! src/share/vm/adlc/formssel.cpp Changeset: 5d871c1ff17c Author: iveresov Date: 2011-09-30 13:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5d871c1ff17c Merge ! make/Makefile ! make/linux/makefiles/defs.make ! make/solaris/makefiles/defs.make ! src/os/linux/vm/os_linux.cpp Changeset: da883b9e6d37 Author: jcoomes Date: 2011-09-30 18:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/da883b9e6d37 Merge ! .hgtags - agent/src/os/solaris/dbx/Makefile - agent/src/os/solaris/dbx/README - agent/src/os/solaris/dbx/README-commands.txt - agent/src/os/solaris/dbx/helloWorld.cpp - agent/src/os/solaris/dbx/proc_service_2.h - agent/src/os/solaris/dbx/shell_imp.h - agent/src/os/solaris/dbx/svc_agent_dbx.cpp - agent/src/os/solaris/dbx/svc_agent_dbx.hpp - agent/src/os/win32/BasicList.hpp - agent/src/os/win32/Buffer.cpp - agent/src/os/win32/Buffer.hpp - agent/src/os/win32/Dispatcher.cpp - agent/src/os/win32/Dispatcher.hpp - agent/src/os/win32/Handler.hpp - agent/src/os/win32/IOBuf.cpp - agent/src/os/win32/IOBuf.hpp - agent/src/os/win32/LockableList.hpp - agent/src/os/win32/Makefile - agent/src/os/win32/Message.hpp - agent/src/os/win32/Monitor.cpp - agent/src/os/win32/Monitor.hpp - agent/src/os/win32/README-commands.txt - agent/src/os/win32/README.txt - agent/src/os/win32/Reaper.cpp - agent/src/os/win32/Reaper.hpp - agent/src/os/win32/SwDbgSrv.cpp - agent/src/os/win32/SwDbgSrv.dsp - agent/src/os/win32/SwDbgSrv.dsw - agent/src/os/win32/SwDbgSub.cpp - agent/src/os/win32/SwDbgSub.dsp - agent/src/os/win32/initWinsock.cpp - agent/src/os/win32/initWinsock.hpp - agent/src/os/win32/ioUtils.cpp - agent/src/os/win32/ioUtils.hpp - agent/src/os/win32/isNT4.cpp - agent/src/os/win32/isNT4.hpp - agent/src/os/win32/libInfo.cpp - agent/src/os/win32/libInfo.hpp - agent/src/os/win32/nt4internals.cpp - agent/src/os/win32/nt4internals.hpp - agent/src/os/win32/ports.h - agent/src/os/win32/procList.cpp - agent/src/os/win32/procList.hpp - agent/src/os/win32/serverLists.cpp - agent/src/os/win32/serverLists.hpp - agent/src/os/win32/toolHelp.cpp - agent/src/os/win32/toolHelp.hpp - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxAddress.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxOopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/AddressDataSource.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/DLL.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestHelloWorld.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Address.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugInfoBuilder.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Debugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32DebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntry.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntryConstants.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32OopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java - make/solaris/makefiles/mapfile-vers-nonproduct - src/share/vm/runtime/reflectionCompat.hpp Changeset: 49ed7eacfd16 Author: jcoomes Date: 2011-09-30 18:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/49ed7eacfd16 Added tag hs23-b01 for changeset da883b9e6d37 ! .hgtags Changeset: 7c20d272643f Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7c20d272643f Added tag jdk8-b08 for changeset 49ed7eacfd16 ! .hgtags Changeset: edd5f85e2de7 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/edd5f85e2de7 Added tag jdk8-b09 for changeset 7c20d272643f ! .hgtags Changeset: 95607b70acb5 Author: jcoomes Date: 2011-09-30 22:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/95607b70acb5 7096124: Bump the hs23 build number to 02 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 4f93f0d00802 Author: tonyp Date: 2011-09-20 09:59 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4f93f0d00802 7059019: G1: add G1 support to the SA Summary: Extend the SA to recognize the G1CollectedHeap and implement any code that's needed by our serviceability tools (jmap, jinfo, jstack, etc.) that depend on the SA. Reviewed-by: never, poonam, johnc ! agent/make/Makefile + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegion.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java ! agent/src/share/classes/sun/jvm/hotspot/gc_interface/CollectedHeapName.java ! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! make/sa.files ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp + src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 663cb89032b1 Author: johnc Date: 2011-09-20 15:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/663cb89032b1 7092412: G1: Some roots not marked during an initial mark that gets an evacuation failure Summary: As a result of the changes for 7080389, an evacuation failure during an initial mark pause may result in some root objects not being marked. Pass whether the caller is a root scanning closure into the evacuation failure handling code so that the thread that successfully forwards an object to itself also marks the object. Reviewed-by: ysr, brutisso, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp Changeset: 114e52976463 Author: tonyp Date: 2011-09-21 01:27 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/114e52976463 7045232: G1: pool names are inconsistent with other collectors (don't have 'Space') Summary: Make sure the eden and survivor pools have "Space" in their name. Reviewed-by: jmasa, ysr ! src/share/vm/services/g1MemoryPool.cpp Changeset: 1847b501ae74 Author: johnc Date: 2011-09-21 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1847b501ae74 7068215: G1: Print reference processing time during remark Summary: Displays the elapsed time taken to perform reference processing during remark as part of the PrintGCDetails output. Reviewed-by: ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: d912b598c6c3 Author: tonyp Date: 2011-09-21 13:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d912b598c6c3 7091032: G1: assert failure when NewRatio is used Summary: The desired min / max heap sizes are miscalculated at initialization when NewRatio is used. The changeset also includes an additional small change to turn a print statement into a warning. Reviewed-by: johnc, jmasa, ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 5cc33133bc6d Author: johnc Date: 2011-09-21 15:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5cc33133bc6d 7092245: G1: Wrong format specifier in G1PrintRegionLivenessInfo header output Summary: Cast HeapRegion::GrainBytes to size_t in output statement. Reviewed-by: ysr, brutisso, pbk, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: f0ecbe78fc7b Author: tonyp Date: 2011-09-22 07:18 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f0ecbe78fc7b 7092238: G1: Uninitialized field gc_efficiency in G1PrintRegionLivenessInfo output Reviewed-by: jcoomes, johnc ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 4dfb2df418f2 Author: johnc Date: 2011-09-22 10:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4dfb2df418f2 6484982: G1: process references during evacuation pauses Summary: G1 now uses two reference processors - one is used by concurrent marking and the other is used by STW GCs (both full and incremental evacuation pauses). In an evacuation pause, the reference processor is embedded into the closures used to scan objects. Doing so causes causes reference objects to be 'discovered' by the reference processor. At the end of the evacuation pause, these discovered reference objects are processed - preserving (and copying) referent objects (and their reachable graphs) as appropriate. Reviewed-by: ysr, jwilhelm, brutisso, stefank, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.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/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/runtime/thread.cpp Changeset: 8229bd737950 Author: tonyp Date: 2011-09-23 16:07 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8229bd737950 7075646: G1: fix inconsistencies in the monitoring data Summary: Fixed a few inconsistencies in the monitoring data, in particular when reported from jstat. Reviewed-by: jmasa, brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/shared/generationCounters.cpp ! src/share/vm/gc_implementation/shared/generationCounters.hpp ! src/share/vm/services/g1MemoryPool.cpp ! src/share/vm/services/g1MemoryPool.hpp Changeset: e807478bf9ca Author: brutisso Date: 2011-09-26 10:14 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e807478bf9ca 7091366: re-enable quicksort tests Summary: Added extern "C" to make it build with JDK6 compilers Reviewed-by: jwilhelm, kvn ! src/share/vm/utilities/quickSort.cpp Changeset: 273b46400613 Author: johnc Date: 2011-09-28 10:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/273b46400613 7086533: G1: assert(!_g1->is_obj_dead(obj)): We should not be preserving dead objs: g1CollectedHeap.cpp:3835 Summary: Some objects may not be marked in the event of an evacuation failure in a partially young GC, during a marking cycle. Avoid this situation by not allowing partially young GCs during a marking cycle. Reviewed-by: tonyp, ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 811ec3d0833b Author: johnc Date: 2011-10-03 12:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/811ec3d0833b 7097053: G1: assert(da ? referent->is_oop() : referent->is_oop_or_null()) failed: referenceProcessor.cpp:1054 Summary: During remembered set scanning, the reference processor could discover a reference object whose referent was in the process of being copied and so may not be completely initialized. Do not perform reference discovery during remembered set scanning. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 81aa07130d30 Author: tonyp Date: 2011-10-03 19:04 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/81aa07130d30 7097048: G1: extend the G1 SA changes to print per-heap space information Reviewed-by: brutisso, johnc ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1MonitoringSupport.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp Changeset: c63b928b212b Author: stefank Date: 2011-09-12 16:09 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c63b928b212b 7021322: assert(object_end <= top()) failed: Object crosses promotion LAB boundary Summary: Pass the same object size value to both allocate and unallocate_object Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp Changeset: 65a8ff39a6da Author: johnc Date: 2011-10-05 08:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/65a8ff39a6da 7095194: G1: HeapRegion::GrainBytes, GrainWords, and CardsPerRegion should be size_t Summary: Declare GrainBytes, GrainWords, and CardsPerRegion as size_t. Reviewed-by: jcoomes, tonyp, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp Changeset: fd65bc7c09b6 Author: tonyp Date: 2011-10-06 13:28 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fd65bc7c09b6 Merge ! agent/make/Makefile ! make/sa.files ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 246daf2c601d Author: brutisso Date: 2011-09-28 08:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/246daf2c601d 7005808: G1: re-enable ReduceInitialCardMarks for G1 Summary: Remove the extra guard to allow G1 to use ReduceInitialCardMarks Reviewed-by: jmasa, tonyp, johnc, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: b9390528617c Author: ysr Date: 2011-10-06 18:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b9390528617c 7095236: G1: _markedRegions never contains NULL regions Summary: Removed the code for skipping over NULL regions in _markedRegions, replacing it with an assertion that a NULL region is never encountered; removed dead methods, remove() and remove_region(), and inlined a simplified addRegion() directly into fillCache(). Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp Changeset: f32dae5d5677 Author: ysr Date: 2011-10-10 08:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f32dae5d5677 Merge Changeset: 3f24f946bc2d Author: brutisso Date: 2011-10-11 10:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3f24f946bc2d 7099454: /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script Summary: Also reviewed by mikael.gerdin at oracle.com; Changed to the `` syntax instead. Also changed "source" to ".". Reviewed-by: never, stefank, dsamersoff, rottenha ! src/os/posix/launcher/launcher.script Changeset: d1bdeef3e3e2 Author: johnc Date: 2011-10-12 10:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d1bdeef3e3e2 7098282: G1: assert(interval >= 0) failed: Sanity check, referencePolicy.cpp: 76 Summary: There is a race between one thread successfully forwarding and copying the klass mirror for the SoftReference class (including the static master clock) and another thread attempting to use the master clock while attempting to discover a soft reference object. Maintain a shadow copy of the soft reference master clock and use the shadow during reference discovery and reference processing. Reviewed-by: tonyp, brutisso, ysr ! src/share/vm/memory/referencePolicy.cpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp Changeset: e4f412d2b75d Author: jcoomes Date: 2011-10-14 18:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e4f412d2b75d Merge ! .hgtags Changeset: d815de2e85e5 Author: jcoomes Date: 2011-10-14 18:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d815de2e85e5 Added tag hs23-b02 for changeset e4f412d2b75d ! .hgtags Changeset: 3170e4044f2d Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3170e4044f2d Added tag jdk8-b10 for changeset d815de2e85e5 ! .hgtags From lana.steuck at oracle.com Wed Oct 26 19:54:40 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 26 Oct 2011 19:54:40 +0000 Subject: hg: jdk8/tl/jdk: 29 new changesets Message-ID: <20111026195933.C1B544713F@hg.openjdk.java.net> Changeset: 19f0a3db863c Author: katleman Date: 2011-09-22 16:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19f0a3db863c Added tag jdk8-b06 for changeset bdb870cc269e ! .hgtags Changeset: ac9349be6821 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac9349be6821 Added tag jdk8-b07 for changeset 19f0a3db863c ! .hgtags Changeset: b92341e9ae56 Author: bae Date: 2011-09-19 05:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b92341e9ae56 7088287: libpng need to be updated. Reviewed-by: jgodinez, prr ! src/share/native/sun/awt/libpng/CHANGES ! src/share/native/sun/awt/libpng/LICENSE ! src/share/native/sun/awt/libpng/README ! src/share/native/sun/awt/libpng/png.c ! src/share/native/sun/awt/libpng/png.h ! src/share/native/sun/awt/libpng/pngconf.h + src/share/native/sun/awt/libpng/pngdebug.h ! src/share/native/sun/awt/libpng/pngerror.c - src/share/native/sun/awt/libpng/pnggccrd.c ! src/share/native/sun/awt/libpng/pngget.c + src/share/native/sun/awt/libpng/pnginfo.h + src/share/native/sun/awt/libpng/pnglibconf.h ! src/share/native/sun/awt/libpng/pngmem.c ! src/share/native/sun/awt/libpng/pngpread.c + src/share/native/sun/awt/libpng/pngpriv.h ! src/share/native/sun/awt/libpng/pngread.c ! src/share/native/sun/awt/libpng/pngrio.c ! src/share/native/sun/awt/libpng/pngrtran.c ! src/share/native/sun/awt/libpng/pngrutil.c ! src/share/native/sun/awt/libpng/pngset.c + src/share/native/sun/awt/libpng/pngstruct.h ! src/share/native/sun/awt/libpng/pngtest.c ! src/share/native/sun/awt/libpng/pngtrans.c - src/share/native/sun/awt/libpng/pngvcrd.c ! src/share/native/sun/awt/libpng/pngwio.c ! src/share/native/sun/awt/libpng/pngwrite.c ! src/share/native/sun/awt/libpng/pngwtran.c ! src/share/native/sun/awt/libpng/pngwutil.c ! src/share/native/sun/awt/splashscreen/splashscreen_png.c Changeset: bbf4e1faf859 Author: lana Date: 2011-09-23 16:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bbf4e1faf859 Merge Changeset: c662c8cf25d6 Author: lana Date: 2011-09-26 14:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c662c8cf25d6 Merge - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: 3487d0d48662 Author: rupashka Date: 2011-09-15 16:43 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3487d0d48662 7090007: Missing style.css in nimbus/doc-files/properties.html Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html Changeset: 16c3dcad4252 Author: rupashka Date: 2011-09-21 17:08 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/16c3dcad4252 7032018: The file list in JFileChooser does not have an accessible name Reviewed-by: rupashka Contributed-by: Charles Lee ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties ! src/share/classes/sun/swing/FilePane.java Changeset: 44040ece133c Author: lana Date: 2011-09-23 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44040ece133c Merge Changeset: 44f50834b79c Author: rupashka Date: 2011-09-26 17:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44f50834b79c 7088744: SwingUtilities.isMiddleMouseButton does not work with ALT/Meta keys Reviewed-by: alexp ! src/share/classes/javax/swing/SwingUtilities.java + test/javax/swing/SwingUtilities/7088744/bug7088744.java Changeset: d72ac458b2b7 Author: anthony Date: 2011-09-26 17:59 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d72ac458b2b7 7081670: Disposing an AppContext can lead to a spinning EventDispatchThread Reviewed-by: art, anthony, dholmes Contributed-by: Clemens Eisserer ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/awt/EventQueue.java Changeset: 7fd192952459 Author: denis Date: 2011-09-26 18:18 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7fd192952459 7080289: AWTKeystroke class registers a subclass factory during deserialization Reviewed-by: serb ! src/share/classes/java/awt/AWTKeyStroke.java Changeset: aac4041609bb Author: lana Date: 2011-09-26 14:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aac4041609bb Merge Changeset: 1c825eac6c04 Author: lana Date: 2011-09-26 14:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c825eac6c04 Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java Changeset: f38b39ed9ed0 Author: lana Date: 2011-10-03 18:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f38b39ed9ed0 Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: 3b59f4bc8046 Author: never Date: 2011-09-07 21:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b59f4bc8046 7082631: JSR 292: need profiling support in GWTs Summary: add CountingMethodHandle Reviewed-by: twisti, jrose ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java + src/share/classes/java/lang/invoke/CountingMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: 7b9a0c75f5d9 Author: jcoomes Date: 2011-09-30 17:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b9a0c75f5d9 Merge Changeset: 1c023bcd0c5a Author: jcoomes Date: 2011-10-04 12:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c023bcd0c5a Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: f1ec21b81421 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1ec21b81421 Added tag jdk8-b08 for changeset 1c023bcd0c5a ! .hgtags Changeset: 7539cc99befe Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7539cc99befe Added tag jdk8-b09 for changeset f1ec21b81421 ! .hgtags Changeset: 1be72d104f9b Author: dbuck Date: 2011-09-26 15:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1be72d104f9b 7029903: Splash screen is not shown in 64-bit Linux with 16-bit color depth Summary: Added Xflush() call after splash screen is updated to ensure update is no stuck in client side buffer until JVM starts up. See JET review request 4154 for details. Reviewed-by: kevinw, anthony ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c Changeset: cfe25bac6951 Author: bagiras Date: 2011-09-27 13:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cfe25bac6951 7073337: Crash after playing Java game on Pogo Reviewed-by: art, uta ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: fcdb588d77ef Author: rupashka Date: 2011-10-05 18:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fcdb588d77ef 7072167: The "root" field in BufferStrategyPaintManager leaks memory Reviewed-by: alexp ! src/share/classes/javax/swing/BufferStrategyPaintManager.java Changeset: 98901d41e1e2 Author: rupashka Date: 2011-10-11 15:22 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98901d41e1e2 7076791: closed/javax/swing/JColorChooser/Test6827032.java failed on windows Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JColorChooser/Test6827032.java ! test/javax/swing/regtesthelpers/Util.java Changeset: 58190ab77d2e Author: lana Date: 2011-10-12 12:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/58190ab77d2e Merge Changeset: eac5d48a6c8e Author: lana Date: 2011-10-12 12:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eac5d48a6c8e Merge Changeset: 4788745572ef Author: lana Date: 2011-10-17 19:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4788745572ef Merge Changeset: 7ab0d613cd1a Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ab0d613cd1a Added tag jdk8-b10 for changeset 4788745572ef ! .hgtags Changeset: 291b55aa9b1e Author: lana Date: 2011-10-25 10:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/291b55aa9b1e Merge - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: 64faf533b99d Author: lana Date: 2011-10-26 12:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64faf533b99d Merge From xuelei.fan at oracle.com Thu Oct 27 02:50:21 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 27 Oct 2011 10:50:21 +0800 Subject: 7094155 Code Review Request In-Reply-To: <4EA802E8.6080505@oracle.com> References: <4EA802E8.6080505@oracle.com> Message-ID: <4EA8C6ED.3070706@oracle.com> Looks fine to me. I also look at some other places that use the Node.getLocalName(). As this method may return null, I was wondering it would be nice if we also make changes to com/sun/org/apache/xml/internal/security/utils/ElementCheckerImpl.java, line 10: 9 if ((el == null) || 10 ns!=el.getNamespaceURI() || !el.getLocalName().equals(type)){ 11 return false; 12 } and signature/Manifest.java, line 337: 334 if ((n.getNodeType() == Node.ELEMENT_NODE) && ((Element) n) 335 .getNamespaceURI() 336 .equals(Constants.SignatureSpecNS) && ((Element) n) 337 .getLocalName().equals(Constants._TAG_MANIFEST)) { and signature/XMLSignature.java, line 318: 317 if ((keyInfoElem != null) && (keyInfoElem.getNamespaceURI().equals (Constants.SignatureSpecNS) && 318 keyInfoElem.getLocalName().equals(Constants._TAG_KEYINFO)) ) { 319 this._keyInfo = new KeyInfo(keyInfoElem, BaseURI); If Node.getLocalName() returns, the above lines might throw NPE. Xuelei On 10/26/2011 8:54 PM, Sean Mullan wrote: > Hi Xuelei, > > Could you please review my fix for 7094155 (JSR105 code throws > javax.xml.crypto.URIReference when running into Java 7 VM)? > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/7094155/webrev.00/ > > Thanks, > Sean From weijun.wang at oracle.com Thu Oct 27 09:24:28 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 27 Oct 2011 09:24:28 +0000 Subject: hg: jdk8/tl/jdk: 7104161: test/sun/tools/jinfo/Basic.sh fails on Ubuntu Message-ID: <20111027092454.1A76D47164@hg.openjdk.java.net> Changeset: 449113aea001 Author: weijun Date: 2011-10-27 17:23 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/449113aea001 7104161: test/sun/tools/jinfo/Basic.sh fails on Ubuntu Reviewed-by: alanb ! test/sun/tools/jinfo/Basic.sh From sean.coffey at oracle.com Thu Oct 27 09:31:50 2011 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Thu, 27 Oct 2011 09:31:50 +0000 Subject: hg: jdk8/tl/jdk: 7099658: Properties.loadFromXML fails with ClassCastException Message-ID: <20111027093201.0187E47165@hg.openjdk.java.net> Changeset: 64ccf18bbad5 Author: coffeys Date: 2011-10-27 10:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64ccf18bbad5 7099658: Properties.loadFromXML fails with ClassCastException Reviewed-by: alanb, mchung ! src/share/classes/sun/util/xml/XMLUtils.java From sean.mullan at oracle.com Thu Oct 27 13:43:30 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 27 Oct 2011 09:43:30 -0400 Subject: 7094155 Code Review Request In-Reply-To: <4EA8C6ED.3070706@oracle.com> References: <4EA802E8.6080505@oracle.com> <4EA8C6ED.3070706@oracle.com> Message-ID: <4EA96002.4070603@oracle.com> On 10/26/11 10:50 PM, Xuelei Fan wrote: > Looks fine to me. > > I also look at some other places that use the Node.getLocalName(). As > this method may return null, I was wondering it would be nice if we also > make changes to > com/sun/org/apache/xml/internal/security/utils/ElementCheckerImpl.java, > line 10: > 9 if ((el == null) || > 10 ns!=el.getNamespaceURI() || !el.getLocalName().equals(type)){ > 11 return false; > 12 } > > and signature/Manifest.java, line 337: > 334 if ((n.getNodeType() == Node.ELEMENT_NODE) && ((Element) n) > 335 .getNamespaceURI() > 336 .equals(Constants.SignatureSpecNS) && ((Element) n) > 337 .getLocalName().equals(Constants._TAG_MANIFEST)) { > > and signature/XMLSignature.java, line 318: > 317 if ((keyInfoElem != null) && (keyInfoElem.getNamespaceURI().equals > (Constants.SignatureSpecNS) && > 318 keyInfoElem.getLocalName().equals(Constants._TAG_KEYINFO)) ) { > 319 this._keyInfo = new KeyInfo(keyInfoElem, BaseURI); > > If Node.getLocalName() returns, the above lines might throw NPE. Possibly, but I would prefer to hold off on that unless I have a specific test case. These code paths above are parsing standard XML Signature elements which must be defined using the DOM APIs with namespace parameters. This is in contrast to the bug fix in which we may be traversing/parsing XML content with no namespace information. Thanks, Sean > > Xuelei > > On 10/26/2011 8:54 PM, Sean Mullan wrote: >> Hi Xuelei, >> >> Could you please review my fix for 7094155 (JSR105 code throws >> javax.xml.crypto.URIReference when running into Java 7 VM)? >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/7094155/webrev.00/ >> >> Thanks, >> Sean > From sebastian.sickelmann at gmx.de Thu Oct 27 14:50:28 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Thu, 27 Oct 2011 16:50:28 +0200 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4E88C03A.90904@gmx.de> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> <4E5E8AE3.3070402@gmx.de> <4E5FE753.2010705@oracle.com> <4E606D1D.6050509@gmx.de> <4E613565.1080801@oracle.com> <4E625E14.9060101@gmx.de> <4E67AF3D.2090609@oracle.com> <4E68FFBD.2030601@gmx.de> <4E6A13A2.2020503@gmx.de> <4E74F05D.7090806@gmx.de> <4E7CD5F8.9000501@oracle.com> <4E7DA91C.2000600@gmx.de> <4E81EDE6.9050205@oracle.com> <4E82A437.30907@gmx.de> <4E86073D.9050101@gmx.de> <4E873DA0.5050906@oracle.com> <4E88C03A.90904@gmx.de> Message-ID: <4EA96FB4.7000502@gmx.de> Some time ago (see below) i ask what would be the right solution to refactor exception initialization to? Solution 1: Disallow calls to initCause after creation, if there was an exception-cause-functionality in this class before it was introduced to Throwable. Solution 2: Disallow calls to initCause after creation with in ctor which has a cause parameter. Solution 3: Disallow calls to initCause after creation, if and only if there are ctors that allows us to specify the cause at creation time. If i investigated it right:: * Solution 1 is used by in the Exceptions in core-libs. * Exceptions that had no cause-chain prior to Throwable's-cause-chain uses Solution 2. * Personally i found Solution 3 is the most intuitive for the users javax/xml/security- Exceptions had cause-chaining prio to Throwable introduces them. jx/x/s-Exceptions are actually not refactored to solution 2 like the other exceptions in core-libs that had cause-chaining prior to Throwable. Before my change-request for jx/x/s-Exceptions i changed some in core-libs (InternalError and VirtualMachineError) to provide exception-chaining. These use Solution 2 like all other exceptions that provided exception-chaining after it where introduced by Throwable. My personal view of this is that i think it may be valueable to change all to Solution 3 or at least merge all Solutions to one Solution(maybe Solution 2) and get rid of Solution 1. I created a webrev[0] for jx/x/s-Exceptions that implements Solution 2 (this can be used for all those Exceptions that used Solution 1 too). And I created a webrev[1] for jx/x/s-Exceptions that implement Solution 3 for comparision. [0] http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html [1] http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.htm The problem with Solution 3 is that bahavoir compatibility is not given and some code may break. -- Sebastian Am 02.10.2011 21:49, schrieb Sebastian Sickelmann: > Am 01.10.2011 18:19, schrieb Sean Mullan: >> On 9/30/11 2:15 PM, Sebastian Sickelmann wrote: >>>>> I think I know the reason. If you allow initCause to be called when a >>>>> cause is >>>>> not initially provided, then getCause will still return null, which >>>>> seems wrong. >>>>> >>>> getCause() of Throwable and all classes that doesn't had a chaining >>>> before >>>> Throwable introduces it, doing this excact this way. Whats wrong on >>>> this? >>>> >>>> return (cause==this ? null : cause); // Where the initial >>>> value(uninitialied) of cause is this. >>> Does this make sense? I actually not sure i understand you right. >> The following code: >> >> KeySelectorException kse = new KeySelectorException("foo"); >> kse.initCause(new Exception("bar")); >> System.out.println(kse.getCause()); >> >> prints null as the cause, even though initCause was subsequently >> called. Do you >> see my concern? > This is one of the places in code which must be changes to match the > initCause behavoir of Throwable. > > I have done it here: > > http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_5/index.html > > > But is this the best way? Or should we just follow the other > Exceptions and start an seperate discussion on this with core-libs-dev? > >>> http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html >>> >> Thanks! >> --Sean >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Thu Oct 27 14:57:35 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 27 Oct 2011 22:57:35 +0800 Subject: 7094155 Code Review Request In-Reply-To: <4EA96002.4070603@oracle.com> References: <4EA802E8.6080505@oracle.com> <4EA8C6ED.3070706@oracle.com> <4EA96002.4070603@oracle.com> Message-ID: <4EA9715F.9080508@oracle.com> On 10/27/2011 9:43 PM, Sean Mullan wrote: > On 10/26/11 10:50 PM, Xuelei Fan wrote: >> Looks fine to me. >> >> I also look at some other places that use the Node.getLocalName(). As >> this method may return null, I was wondering it would be nice if we also >> make changes to >> com/sun/org/apache/xml/internal/security/utils/ElementCheckerImpl.java, >> line 10: >> 9 if ((el == null) || >> 10 ns!=el.getNamespaceURI() || !el.getLocalName().equals(type)){ >> 11 return false; >> 12 } >> >> and signature/Manifest.java, line 337: >> 334 if ((n.getNodeType() == Node.ELEMENT_NODE) && ((Element) n) >> 335 .getNamespaceURI() >> 336 .equals(Constants.SignatureSpecNS) && ((Element) n) >> 337 .getLocalName().equals(Constants._TAG_MANIFEST)) { >> >> and signature/XMLSignature.java, line 318: >> 317 if ((keyInfoElem != null) && (keyInfoElem.getNamespaceURI().equals >> (Constants.SignatureSpecNS) && >> 318 keyInfoElem.getLocalName().equals(Constants._TAG_KEYINFO)) ) { >> 319 this._keyInfo = new KeyInfo(keyInfoElem, BaseURI); >> >> If Node.getLocalName() returns, the above lines might throw NPE. > > Possibly, but I would prefer to hold off on that unless I have a specific test > case. These code paths above are parsing standard XML Signature elements which > must be defined using the DOM APIs with namespace parameters. This is in > contrast to the bug fix in which we may be traversing/parsing XML content with > no namespace information. > Sounds fine to me. Xuelei > Thanks, > Sean > >> >> Xuelei >> >> On 10/26/2011 8:54 PM, Sean Mullan wrote: >>> Hi Xuelei, >>> >>> Could you please review my fix for 7094155 (JSR105 code throws >>> javax.xml.crypto.URIReference when running into Java 7 VM)? >>> >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/7094155/webrev.00/ >>> >>> Thanks, >>> Sean >> From sean.mullan at oracle.com Thu Oct 27 15:17:37 2011 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 27 Oct 2011 15:17:37 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20111027151832.25C2A4716A@hg.openjdk.java.net> Changeset: 56cc907fc8dc Author: mullan Date: 2011-10-27 10:57 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56cc907fc8dc 7094155: JSR105 code throws javax.xml.crypto.URIReferenceException when running into Java 7 VM Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java ! test/javax/xml/crypto/dsig/GenerationTests.java Changeset: 8cd2e3b8127a Author: mullan Date: 2011-10-27 11:01 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8cd2e3b8127a Merge - make/sun/rmi/rmi/mapfile-vers - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c - src/share/native/sun/rmi/server/MarshalInputStream.c From xuelei.fan at oracle.com Fri Oct 28 13:19:22 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 28 Oct 2011 21:19:22 +0800 Subject: Code review request: 7105940, Test regression: KeyStore must be from provider SunPKCS11-NSSKeyStore Message-ID: <4EAAABDA.6090609@oracle.com> Hi Weijun, Would you please review my fix for 7105940(Test regression: KeyStore must be from provider SunPKCS11-NSSKeyStore)? webrev: http://cr.openjdk.java.net/~xuelei/7105940/webrev.00/ Thanks, Xuelei From weijun.wang at oracle.com Fri Oct 28 13:53:03 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 28 Oct 2011 21:53:03 +0800 Subject: Code review request: 7105940, Test regression: KeyStore must be from provider SunPKCS11-NSSKeyStore In-Reply-To: <4EAAABDA.6090609@oracle.com> References: <4EAAABDA.6090609@oracle.com> Message-ID: <4EAAB3BF.3040400@oracle.com> CipherTest looks fine. What is the change in ClientJSSEServerJSSE for? Maybe you meant to remove the @ignore line? Thanks Weijun On 10/28/2011 09:19 PM, Xuelei Fan wrote: > Hi Weijun, > > Would you please review my fix for 7105940(Test regression: KeyStore > must be from provider SunPKCS11-NSSKeyStore)? > > webrev: http://cr.openjdk.java.net/~xuelei/7105940/webrev.00/ > > Thanks, > Xuelei From xuelei.fan at oracle.com Fri Oct 28 13:55:19 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 28 Oct 2011 21:55:19 +0800 Subject: Code review request: 7105940, Test regression: KeyStore must be from provider SunPKCS11-NSSKeyStore In-Reply-To: <4EAAB3BF.3040400@oracle.com> References: <4EAAABDA.6090609@oracle.com> <4EAAB3BF.3040400@oracle.com> Message-ID: <4EAAB447.8070301@oracle.com> Move forward the @run tag, so that it can be really ignored by @ignore tag. Otherwise, it will be run as normal. That's also why I can catch the exception. Thanks, Xuelei On 10/28/2011 9:53 PM, Weijun Wang wrote: > CipherTest looks fine. What is the change in ClientJSSEServerJSSE for? > Maybe you meant to remove the @ignore line? > > Thanks > Weijun > > > On 10/28/2011 09:19 PM, Xuelei Fan wrote: >> Hi Weijun, >> >> Would you please review my fix for 7105940(Test regression: KeyStore >> must be from provider SunPKCS11-NSSKeyStore)? >> >> webrev: http://cr.openjdk.java.net/~xuelei/7105940/webrev.00/ >> >> Thanks, >> Xuelei From weijun.wang at oracle.com Fri Oct 28 14:05:01 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 28 Oct 2011 22:05:01 +0800 Subject: Code review request: 7105940, Test regression: KeyStore must be from provider SunPKCS11-NSSKeyStore In-Reply-To: <4EAAB447.8070301@oracle.com> References: <4EAAABDA.6090609@oracle.com> <4EAAB3BF.3040400@oracle.com> <4EAAB447.8070301@oracle.com> Message-ID: <4EAAB68D.3000208@oracle.com> Oh, really? On my Linux it's always ignored. What did you mean "When run the test manually"? javac and java it? Anyway, the fix is correct. You can putback it. Thanks Max On 10/28/2011 09:55 PM, Xuelei Fan wrote: > Move forward the @run tag, so that it can be really ignored by @ignore > tag. Otherwise, it will be run as normal. That's also why I can catch > the exception. > > Thanks, > Xuelei > > On 10/28/2011 9:53 PM, Weijun Wang wrote: >> CipherTest looks fine. What is the change in ClientJSSEServerJSSE for? >> Maybe you meant to remove the @ignore line? >> >> Thanks >> Weijun >> >> >> On 10/28/2011 09:19 PM, Xuelei Fan wrote: >>> Hi Weijun, >>> >>> Would you please review my fix for 7105940(Test regression: KeyStore >>> must be from provider SunPKCS11-NSSKeyStore)? >>> >>> webrev: http://cr.openjdk.java.net/~xuelei/7105940/webrev.00/ >>> >>> Thanks, >>> Xuelei > From xuelei.fan at oracle.com Fri Oct 28 14:07:04 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 28 Oct 2011 22:07:04 +0800 Subject: Code review request: 7105940, Test regression: KeyStore must be from provider SunPKCS11-NSSKeyStore In-Reply-To: <4EAAB68D.3000208@oracle.com> References: <4EAAABDA.6090609@oracle.com> <4EAAB3BF.3040400@oracle.com> <4EAAB447.8070301@oracle.com> <4EAAB68D.3000208@oracle.com> Message-ID: <4EAAB708.1070306@oracle.com> On 10/28/2011 10:05 PM, Weijun Wang wrote: > Oh, really? On my Linux it's always ignored. > Yes, it's true. If I'm correct, I also address similar issues on other CRs. > What did you mean "When run the test manually"? javac and java it? > By remove @ignore tag, and jtreg. > Anyway, the fix is correct. You can putback it. > Thanks! Xuelei > Thanks > Max > > On 10/28/2011 09:55 PM, Xuelei Fan wrote: >> Move forward the @run tag, so that it can be really ignored by @ignore >> tag. Otherwise, it will be run as normal. That's also why I can catch >> the exception. >> >> Thanks, >> Xuelei >> >> On 10/28/2011 9:53 PM, Weijun Wang wrote: >>> CipherTest looks fine. What is the change in ClientJSSEServerJSSE for? >>> Maybe you meant to remove the @ignore line? >>> >>> Thanks >>> Weijun >>> >>> >>> On 10/28/2011 09:19 PM, Xuelei Fan wrote: >>>> Hi Weijun, >>>> >>>> Would you please review my fix for 7105940(Test regression: KeyStore >>>> must be from provider SunPKCS11-NSSKeyStore)? >>>> >>>> webrev: http://cr.openjdk.java.net/~xuelei/7105940/webrev.00/ >>>> >>>> Thanks, >>>> Xuelei >> From xuelei.fan at oracle.com Fri Oct 28 14:20:32 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 28 Oct 2011 14:20:32 +0000 Subject: hg: jdk8/tl/jdk: 7105940: Test regression: KeyStore must be from provider SunPKCS11-NSSKeyStore Message-ID: <20111028142059.6EA9B471B2@hg.openjdk.java.net> Changeset: 6e59c482e9b8 Author: xuelei Date: 2011-10-28 07:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6e59c482e9b8 7105940: Test regression: KeyStore must be from provider SunPKCS11-NSSKeyStore Reviewed-by: weijun ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java From bradford.wetmore at oracle.com Sat Oct 29 00:47:58 2011 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Fri, 28 Oct 2011 17:47:58 -0700 Subject: Review 7105792: Remove sun/security/pkcs11/Provider/Absolute.java from JPRT testing. No windows-x64 impl. Message-ID: <4EAB4D3E.900@oracle.com> Hi Valerie, http://cr.openjdk.java.net/~wetmore/7105792/ 7105792: Remove sun/security/pkcs11/Provider/Absolute.java from JPRT testing. No windows-x64 impl. As you know, there is a broken JDK test on windows-x64 under the jdk_security3 target. It doesn't compile due to a missing library PKCS11 (bug: 6880559), and someone has to manually check that failure. (Obviously, it was me last time, thus the bug! ;) ) In JDK8, Weijun added this test to the test/ProblemList.txt file as part of the jdk_security3 test cleanup. Just doing the same for 7u. This removal is just a small part of the larger test cleanup. Yay/nay? Brad From bradford.wetmore at oracle.com Sat Oct 29 00:48:33 2011 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Fri, 28 Oct 2011 17:48:33 -0700 Subject: Review: 7105780: Add SSLSocket client/SSLEngine server to templates directory Message-ID: <4EAB4D61.8040009@oracle.com> Hi Andrew, Wrapping up some loose ends. I was thinking it would be a good idea to put the test case for the recent Bad MAC error into the JSSE test template directory. It might be useful to have a SSLSocket client that can easily talk to a SSLEngine server. If we keep this test buried down in sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl, it'll easily be forgotten. I made a few very minor changes to the test: 7105780: Add SSLSocket client/SSLEngine server to templates directory http://cr.openjdk.java.net/~wetmore/7105780/webrev.00/ What do you think? Brad From xuelei.fan at oracle.com Sat Oct 29 01:59:24 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 29 Oct 2011 09:59:24 +0800 Subject: Review: 7105780: Add SSLSocket client/SSLEngine server to templates directory In-Reply-To: <4EAB4D61.8040009@oracle.com> References: <4EAB4D61.8040009@oracle.com> Message-ID: <4EAB5DFC.3060203@oracle.com> It's a good idea to move it to template directory. I did quick look at the code, looks fine to me. I did not read the code line by line carefully, hopefully, there is no significant changes from previous test. Just a minor suggest, it would be better if moving the @run tag at the bottom of the comment. Otherwise, the "SunJSSE does not support ..." would become the parameters of the command. I just noticed the issue recently. * @summary Add SSLSocket client/SSLEngine server to templates directory -* @run main/othervm SSLSocketSSLEngineTemplate * * SunJSSE does not support dynamic system properties, no way to * re-use system properties in samevm/agentvm mode. +* @run main/othervm SSLSocketSSLEngineTemplate */ Thanks, Xuelei On 10/29/2011 8:48 AM, Brad Wetmore wrote: > Hi Andrew, > > Wrapping up some loose ends. I was thinking it would be a good idea to > put the test case for the recent Bad MAC error into the JSSE test > template directory. It might be useful to have a SSLSocket client that > can easily talk to a SSLEngine server. If we keep this test buried down > in sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl, it'll > easily be forgotten. > > I made a few very minor changes to the test: > > 7105780: Add SSLSocket client/SSLEngine server to templates directory > > http://cr.openjdk.java.net/~wetmore/7105780/webrev.00/ > > What do you think? > > Brad > > > From xuelei.fan at oracle.com Sat Oct 29 03:00:05 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 29 Oct 2011 11:00:05 +0800 Subject: Code review request: 7106277 Brokenness in the seqNumberOverflow of MAC Message-ID: <4EAB6C35.1040003@oracle.com> Hi, Would you please review my fix for 7106277 (Brokenness in the seqNumberOverflow of MAC)? webrev: http://cr.openjdk.java.net/~xuelei/7106277/webrev.00/ Thanks, Xuelei From bradford.wetmore at oracle.com Sat Oct 29 05:04:46 2011 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 28 Oct 2011 22:04:46 -0700 Subject: Code review request: 7106277 Brokenness in the seqNumberOverflow of MAC In-Reply-To: <4EAB6C35.1040003@oracle.com> References: <4EAB6C35.1040003@oracle.com> Message-ID: <4EAB896E.3020805@oracle.com> Looks good. As you may remember, my personal preference is to use lots of parens to clearly show what you intended, but up to you as it's pretty clear without return ((block != null) && (mac != null) && (block[0] == (byte)0xFF) && (block[1] == (byte)0xFF) && ... I'd ask for a test case, but it might take a while to run. ;) Brad On 10/28/2011 8:00 PM, Xuelei Fan wrote: > Hi, > > Would you please review my fix for 7106277 (Brokenness in the > seqNumberOverflow of MAC)? > > webrev: http://cr.openjdk.java.net/~xuelei/7106277/webrev.00/ > > Thanks, > Xuelei From xuelei.fan at oracle.com Sat Oct 29 05:40:26 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 29 Oct 2011 13:40:26 +0800 Subject: Code review request: 7106277 Brokenness in the seqNumberOverflow of MAC In-Reply-To: <4EAB896E.3020805@oracle.com> References: <4EAB6C35.1040003@oracle.com> <4EAB896E.3020805@oracle.com> Message-ID: <4EAB91CA.9010404@oracle.com> On 10/29/2011 1:04 PM, Bradford Wetmore wrote: > Looks good. As you may remember, my personal preference is to use lots > of parens to clearly show what you intended, but up to you as it's > pretty clear without > > return ((block != null) && (mac != null) && > (block[0] == (byte)0xFF) && (block[1] == (byte)0xFF) && > ... > > I'd ask for a test case, but it might take a while to run. ;) > Quite a while, it would require a few weeks (even years) at least to reach a huge record sequence number on a normal computer. I don't think we are patient enough to observe the test result. ;-) Thanks for the review. Xuelei > Brad > > > > > > On 10/28/2011 8:00 PM, Xuelei Fan wrote: >> Hi, >> >> Would you please review my fix for 7106277 (Brokenness in the >> seqNumberOverflow of MAC)? >> >> webrev: http://cr.openjdk.java.net/~xuelei/7106277/webrev.00/ >> >> Thanks, >> Xuelei From sebastian.sickelmann at gmx.de Sat Oct 29 11:17:41 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Sat, 29 Oct 2011 13:17:41 +0200 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4EA96FB4.7000502@gmx.de> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> <4E5E8AE3.3070402@gmx.de> <4E5FE753.2010705@oracle.com> <4E606D1D.6050509@gmx.de> <4E613565.1080801@oracle.com> <4E625E14.9060101@gmx.de> <4E67AF3D.2090609@oracle.com> <4E68FFBD.2030601@gmx.de> <4E6A13A2.2020503@gmx.de> <4E74F05D.7090806@gmx.de> <4E7CD5F8.9000501@oracle.com> <4E7DA91C.2000600@gmx.de> <4E81EDE6.9050205@oracle.com> <4E82A437.30907@gmx.de> <4E86073D.9050101@gmx.de> <4E873DA0.5050906@oracle.com> <4E88C03A.90904@gmx.de> <4EA96FB4.7000502@gmx.de> Message-ID: <4EABE0D5.5050802@gmx.de> Sorry i linked the wrong webrev for Solution 3. Am 27.10.2011 16:50, schrieb Sebastian Sickelmann: > Some time ago (see below) i ask what would be the right solution to > refactor > exception initialization to? > > Solution 1: Disallow calls to initCause after creation, if there was an > exception-cause-functionality in this class before it was introduced > to Throwable. > Solution 2: Disallow calls to initCause after creation with in ctor > which has a cause parameter. > Solution 3: Disallow calls to initCause after creation, if and only if > there are ctors > that allows us to specify the cause at creation time. > > > If i investigated it right:: > * Solution 1 is used by in the Exceptions in core-libs. > * Exceptions that had no cause-chain prior to > Throwable's-cause-chain uses Solution 2. > * Personally i found Solution 3 is the most intuitive for the users > > javax/xml/security- Exceptions had cause-chaining prio to Throwable > introduces them. jx/x/s-Exceptions are actually not refactored to > solution 2 like the other exceptions in core-libs that had > cause-chaining prior to Throwable. > > Before my change-request for jx/x/s-Exceptions i changed some in > core-libs (InternalError and VirtualMachineError) to provide > exception-chaining. These use Solution 2 like all other exceptions > that provided exception-chaining after it where introduced by Throwable. > > My personal view of this is that i think it may be valueable to change > all to Solution 3 or at least merge all Solutions to one > Solution(maybe Solution 2) and get rid of Solution 1. > I created a webrev[0] for jx/x/s-Exceptions that implements Solution 2 > (this can be used for all those Exceptions that used Solution 1 too). > And I created a webrev[1] for jx/x/s-Exceptions that implement > Solution 3 for comparision. > > [0] > http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html > [1] http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_6/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Sat Oct 29 16:29:36 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sat, 29 Oct 2011 09:29:36 -0700 Subject: JEP 113: MS-SFU Kerberos 5 Extensions Message-ID: <20111029162936.75C9E1877@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/113 - Mark From mark.reinhold at oracle.com Sat Oct 29 16:41:43 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sat, 29 Oct 2011 09:41:43 -0700 Subject: JEP 114: TLS Server Name Indication (SNI) Extension Message-ID: <20111029164143.42E7F1877@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/114 - Mark From mark.reinhold at oracle.com Sat Oct 29 16:50:05 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sat, 29 Oct 2011 09:50:05 -0700 Subject: JEP 115: AEAD CipherSuites Message-ID: <20111029165005.EE42E1877@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/115 - Mark From mark.reinhold at oracle.com Sat Oct 29 17:03:06 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sat, 29 Oct 2011 10:03:06 -0700 Subject: JEP 116: Extended Validation Certificates Message-ID: <20111029170306.443CC1877@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/116 - Mark From alan.bateman at oracle.com Sun Oct 30 15:04:17 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 30 Oct 2011 15:04:17 +0000 Subject: hg: jdk8/tl/jdk: 7103889: (fs) Reduce String concatenation when iterating over directory Message-ID: <20111030150450.0B091471D3@hg.openjdk.java.net> Changeset: bb2b9a8b6e77 Author: alanb Date: 2011-10-30 14:53 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb2b9a8b6e77 7103889: (fs) Reduce String concatenation when iterating over directory Reviewed-by: alanb Contributed-by: mike.skells at talk21.com ! src/share/classes/java/nio/file/Files.java ! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java ! src/windows/classes/sun/nio/fs/WindowsPathParser.java From xuelei.fan at oracle.com Mon Oct 31 03:09:13 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 31 Oct 2011 03:09:13 +0000 Subject: hg: jdk8/tl/jdk: 7106277: Brokenness in the seqNumberOverflow of MAC Message-ID: <20111031030931.47B4A471D4@hg.openjdk.java.net> Changeset: 30900a1a9cfc Author: xuelei Date: 2011-10-30 20:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/30900a1a9cfc 7106277: Brokenness in the seqNumberOverflow of MAC Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/MAC.java From valerie.peng at oracle.com Mon Oct 31 17:02:43 2011 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Mon, 31 Oct 2011 10:02:43 -0700 Subject: Review 7105792: Remove sun/security/pkcs11/Provider/Absolute.java from JPRT testing. No windows-x64 impl. In-Reply-To: <4EAB4D3E.900@oracle.com> References: <4EAB4D3E.900@oracle.com> Message-ID: <4EAED4B3.1000603@oracle.com> Yay. Thanks, Valerie On 10/28/11 17:47, Brad Wetmore wrote: > > Hi Valerie, > > http://cr.openjdk.java.net/~wetmore/7105792/ > > 7105792: Remove sun/security/pkcs11/Provider/Absolute.java from JPRT > testing. No windows-x64 impl. > > As you know, there is a broken JDK test on windows-x64 under the > jdk_security3 target. It doesn't compile due to a missing library > PKCS11 (bug: 6880559), and someone has to manually check that > failure. (Obviously, it was me last time, thus the bug! ;) ) > > In JDK8, Weijun added this test to the test/ProblemList.txt file as > part of the jdk_security3 test cleanup. Just doing the same for 7u. > This removal is just a small part of the larger test cleanup. > > Yay/nay? > > Brad > > From bradford.wetmore at oracle.com Mon Oct 31 18:47:44 2011 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Mon, 31 Oct 2011 11:47:44 -0700 Subject: Review: 7105780: Add SSLSocket client/SSLEngine server to templates directory In-Reply-To: <4EAB5DFC.3060203@oracle.com> References: <4EAB4D61.8040009@oracle.com> <4EAB5DFC.3060203@oracle.com> Message-ID: <4EAEED50.6020300@oracle.com> Done, thanks. Brad On 10/28/2011 6:59 PM, Xuelei Fan wrote: > It's a good idea to move it to template directory. I did quick look at > the code, looks fine to me. I did not read the code line by line > carefully, hopefully, there is no significant changes from previous test. > > Just a minor suggest, it would be better if moving the @run tag at the > bottom of the comment. Otherwise, the "SunJSSE does not support ..." > would become the parameters of the command. I just noticed the issue > recently. > > * @summary Add SSLSocket client/SSLEngine server to templates directory > -* @run main/othervm SSLSocketSSLEngineTemplate > * > * SunJSSE does not support dynamic system properties, no way to > * re-use system properties in samevm/agentvm mode. > +* @run main/othervm SSLSocketSSLEngineTemplate > */ > > Thanks, > Xuelei > > On 10/29/2011 8:48 AM, Brad Wetmore wrote: >> Hi Andrew, >> >> Wrapping up some loose ends. I was thinking it would be a good idea to >> put the test case for the recent Bad MAC error into the JSSE test >> template directory. It might be useful to have a SSLSocket client that >> can easily talk to a SSLEngine server. If we keep this test buried down >> in sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl, it'll >> easily be forgotten. >> >> I made a few very minor changes to the test: >> >> 7105780: Add SSLSocket client/SSLEngine server to templates directory >> >> http://cr.openjdk.java.net/~wetmore/7105780/webrev.00/ >> >> What do you think? >> >> Brad >> >> >> > From bradford.wetmore at oracle.com Mon Oct 31 18:55:37 2011 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Mon, 31 Oct 2011 18:55:37 +0000 Subject: hg: jdk8/tl/jdk: 7105780: Add SSLSocket client/SSLEngine server to templates directory Message-ID: <20111031185547.7C43D471DB@hg.openjdk.java.net> Changeset: 8681362a2f04 Author: wetmore Date: 2011-10-31 11:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8681362a2f04 7105780: Add SSLSocket client/SSLEngine server to templates directory Reviewed-by: xuelei + test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java From bradford.wetmore at oracle.com Mon Oct 31 21:19:26 2011 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Mon, 31 Oct 2011 14:19:26 -0700 Subject: Review 7053252: New regression test does not compile on windows-amd64 Message-ID: <4EAF10DE.4050506@oracle.com> Hi Valerie, http://cr.openjdk.java.net/~wetmore/7053252/ Review 7053252: New regression test does not compile on windows-amd64 As you know, there is a broken JDK test on windows-x64 under the jdk_security3 target (no pkcs11 library, thus the import fails on compile). Someone has to manually check this failure. (Obviously, it was me last time, thus the bug! ;) ) Removing the incorrect import in both jdk7u/jdk8. Brad From valerie.peng at oracle.com Mon Oct 31 22:33:44 2011 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Mon, 31 Oct 2011 15:33:44 -0700 Subject: Review 7053252: New regression test does not compile on windows-amd64 In-Reply-To: <4EAF10DE.4050506@oracle.com> References: <4EAF10DE.4050506@oracle.com> Message-ID: <4EAF2248.1050507@oracle.com> Looks good to me. Valerie On 10/31/11 14:19, Brad Wetmore wrote: > > Hi Valerie, > > http://cr.openjdk.java.net/~wetmore/7053252/ > > Review 7053252: New regression test does not compile on windows-amd64 > > As you know, there is a broken JDK test on windows-x64 under the > jdk_security3 target (no pkcs11 library, thus the import fails on > compile). Someone has to manually check this failure. (Obviously, it > was me last time, thus the bug! ;) ) > > Removing the incorrect import in both jdk7u/jdk8. > > Brad > > From bradford.wetmore at oracle.com Mon Oct 31 23:24:50 2011 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Mon, 31 Oct 2011 23:24:50 +0000 Subject: hg: jdk8/tl/jdk: 7053252: New regression test does not compile on windows-amd64 Message-ID: <20111031232500.1E7B1471E7@hg.openjdk.java.net> Changeset: b60e88ef5d8d Author: wetmore Date: 2011-10-31 16:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b60e88ef5d8d 7053252: New regression test does not compile on windows-amd64 Reviewed-by: valeriep ! test/ProblemList.txt ! test/sun/security/pkcs11/Provider/Absolute.java