Re: Code Review Request: 7183800: TEST_BUG: Update tests to run on Ubuntu 12.04 (localhost is 127.0.1.1)
On 15/07/2012 19:54, Kurchi Subhra Hazra wrote: Hi, Some tests in our test repository assume that InetAddress.getLocalHost() will return 127.0.0.1. However, with linux systems running Ubuntu 12.04 now returning 127.0.1.1 as localhost, these tests are failing. I have changed two of the NIO tests to remove their dependency on InetAddress.getLocalHost(). A third test has been added to the ProblemList.txt since the changes required for it are more involved. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7183800 Webrev: http://cr.openjdk.java.net/~khazra/7183800/webrev.00/ As Chris pointed out, these tests bind to the wildcard address and you need a specific address to setup the address association, otherwise it's highly platform/implementation specific as to whether it will do as intended. So I think the proposed changes will cause problems where you can't connect to 0.0.0.0 and so I think we need to look for another solution. Given that none of the TCP tests fail then it suggests it mean that something else is going on, maybe something in the Ubuntu 12 configuration. Do these tests run if IPv6 is disabled? We've had issues with some distributions where multicast tests fail and these have always come down to iptables blocking IPv6 multicast packets causing the tests to fail. I just wonder if we have something similar here. -Alan
Re: Code Review Request 7142596: RMI JPRT tests are failing
Hi Darryl, Sorry, I'm going to have to ask you to update this again. The issues are in TestLibrary.java and are all related to catching exceptions and throwing new exception instances, discarding the original exception (and probably relevant diagnostic information) in the process. Let's get together today and work on it. I expect it will take only half an hour or so to knock things out. s'marks On 7/13/12 1:40 PM, Darryl Mocek wrote: On 07/12/2012 05:13 PM, Stuart Marks wrote: OK, I took a look at the revised webrev. Most stuff is good. A couple changes are necessary though. *** MultipleRegistries.java Not a big deal, but the comment at lines 65-67 is no longer necessary. Comment removed. *** TestLibrary.java I think the reserved port range stuff still needs to be fixed up. The comment at lines 81-82 talks about a range 64000-64100 which isn't really present anywhere. The comment should instead say that PORT_MIN and PORT_MAX should be kept adjusted so that they specify the range of ports defined by the constants following. Make sure to do this adjustment; PORT_MAX is 64002 here. I reserved ports 64000-64100 (even though only 64001-64005 are currently being used) for fixed port tests (for tests which require fixed ports) so any future tests which require fixed ports can be assured there are ports available within a range for their use. In fixing the tests, I saw that those who wrote tests and used fixed ports grabbed random port numbers all over the place. Providing a reserved range allows them to just grab the next number and to keep the fixed port numbers in a group, even when new tests are added. If the ports are defined in a central place, like TestLibrary, then hopefully developers will come to TestLibrary to reserve the ports rather then define them in the tests themselves, like was done previously. I chose 100 ports for future-proofing...I don't think 100 is too many, but I've reduced it to 10 and lowered the max to 64010. I was also thinking of looking for tests which used fixed ports outside of RMI tests and standardizing those ports here, but that's possible future work and I'm not sure it's necessary. The previous webrev had PORT_MIN and PORT_MAX specify a range of 1024-64000 as the *allowed* range for ports returned by getUnusedRandomPort(). But as I described previously, this is difficult to enforce given the varying port allocation schemes on different OSes. Instead I think we need to invert the sense of the range PORT_MIN..PORT_MAX and make it be the range of ports reserved by tests that require fixed ports (64001 through 64005). Then, getUnusedRandomPort() needs to be changed to *disallow* ports in this range, that is, to retry if the port is within this range. Thus the condition on the while-loop has to be inverted, something like while (... unusedRandomPort = PORT_MIN unusedRandomPort = PORT_MAX) Yes, this is correct and it has been changed. So, how could getUnusedRandomPort() have worked in its present state? Well I think it ends up retrying 10 times, then at the end of the loop unusedRandomPort is actually some legal port number -- albeit possibly one within the disallowed range -- and almost certainly not -1, and so the method returns it and the caller uses it. So, the success-testing logic here will also have to change so that it retests whether the port is in the disallowed range. Correct...done. The comment on getUnusedRandomPort() also needs to be updated to reflect its new policy on the reserved range, as well as throwing an exception on failure. Also (nitpick) it should say less than not less then. Yes, I always do this. :( Looking at getUnusedRandomPort() again more closely [sorry] I think the catch of Exception that does nothing is suspicious. I'm not sure why getting a ServerSocket would fail, but if it does (maybe the system is out of ports??) we should just throw out to the caller. Perhaps ideally we'd just have this method throw IOException, but if that requires all callers to be updated, it might be easier just to catch IOException and throw a RuntimeException that wraps the caught IOException. I see no harm in trying again if it fails. If we have run out of ports, then possibly one or more used ports will be closed and freed and a subsequent try will succeed. I don't know all of the cases where a failure might occur. Anyway, if this is the prevailing way of handling this, I'll change it. Similar comments apply to the catch(Exception)/do-nothing code in the other utility methods. Now throwing RuntimeException in getRegistryPort. Certainly getRegistryPort() should just throw (or possibly wrap and rethrow) any exception caught. For createRegistryOnUnusedPort(), the catching of ExportException is handled properly. The second catch clause of the outer try-block, and the catch of the inner try-block, both ignore exceptions. The code will then end up retrying. Is it reasonable that retrying in these cases will result in a
Re: Code Review Request 7142596: RMI JPRT tests are failing
After looking at it again, technically, we ought to remove the fixed ports from the list of ports available to the RMI Registry (OK, so this isn't a BIG deal). Using SocketFactory's as Alan suggests will solve this problem as well. Darryl On 07/16/2012 08:42 AM, Stuart Marks wrote: Hi Darryl, Sorry, I'm going to have to ask you to update this again. The issues are in TestLibrary.java and are all related to catching exceptions and throwing new exception instances, discarding the original exception (and probably relevant diagnostic information) in the process. Let's get together today and work on it. I expect it will take only half an hour or so to knock things out. s'marks On 7/13/12 1:40 PM, Darryl Mocek wrote: On 07/12/2012 05:13 PM, Stuart Marks wrote: OK, I took a look at the revised webrev. Most stuff is good. A couple changes are necessary though. *** MultipleRegistries.java Not a big deal, but the comment at lines 65-67 is no longer necessary. Comment removed. *** TestLibrary.java I think the reserved port range stuff still needs to be fixed up. The comment at lines 81-82 talks about a range 64000-64100 which isn't really present anywhere. The comment should instead say that PORT_MIN and PORT_MAX should be kept adjusted so that they specify the range of ports defined by the constants following. Make sure to do this adjustment; PORT_MAX is 64002 here. I reserved ports 64000-64100 (even though only 64001-64005 are currently being used) for fixed port tests (for tests which require fixed ports) so any future tests which require fixed ports can be assured there are ports available within a range for their use. In fixing the tests, I saw that those who wrote tests and used fixed ports grabbed random port numbers all over the place. Providing a reserved range allows them to just grab the next number and to keep the fixed port numbers in a group, even when new tests are added. If the ports are defined in a central place, like TestLibrary, then hopefully developers will come to TestLibrary to reserve the ports rather then define them in the tests themselves, like was done previously. I chose 100 ports for future-proofing...I don't think 100 is too many, but I've reduced it to 10 and lowered the max to 64010. I was also thinking of looking for tests which used fixed ports outside of RMI tests and standardizing those ports here, but that's possible future work and I'm not sure it's necessary. The previous webrev had PORT_MIN and PORT_MAX specify a range of 1024-64000 as the *allowed* range for ports returned by getUnusedRandomPort(). But as I described previously, this is difficult to enforce given the varying port allocation schemes on different OSes. Instead I think we need to invert the sense of the range PORT_MIN..PORT_MAX and make it be the range of ports reserved by tests that require fixed ports (64001 through 64005). Then, getUnusedRandomPort() needs to be changed to *disallow* ports in this range, that is, to retry if the port is within this range. Thus the condition on the while-loop has to be inverted, something like while (... unusedRandomPort = PORT_MIN unusedRandomPort = PORT_MAX) Yes, this is correct and it has been changed. So, how could getUnusedRandomPort() have worked in its present state? Well I think it ends up retrying 10 times, then at the end of the loop unusedRandomPort is actually some legal port number -- albeit possibly one within the disallowed range -- and almost certainly not -1, and so the method returns it and the caller uses it. So, the success-testing logic here will also have to change so that it retests whether the port is in the disallowed range. Correct...done. The comment on getUnusedRandomPort() also needs to be updated to reflect its new policy on the reserved range, as well as throwing an exception on failure. Also (nitpick) it should say less than not less then. Yes, I always do this. :( Looking at getUnusedRandomPort() again more closely [sorry] I think the catch of Exception that does nothing is suspicious. I'm not sure why getting a ServerSocket would fail, but if it does (maybe the system is out of ports??) we should just throw out to the caller. Perhaps ideally we'd just have this method throw IOException, but if that requires all callers to be updated, it might be easier just to catch IOException and throw a RuntimeException that wraps the caught IOException. I see no harm in trying again if it fails. If we have run out of ports, then possibly one or more used ports will be closed and freed and a subsequent try will succeed. I don't know all of the cases where a failure might occur. Anyway, if this is the prevailing way of handling this, I'll change it. Similar comments apply to the catch(Exception)/do-nothing code in the other utility methods. Now throwing RuntimeException in getRegistryPort. Certainly getRegistryPort() should just throw (or possibly wrap
Re: Codereview request for 6653797: Reimplement JDK charset repository charsets.jar
On 7/16/2012 9:30 AM, Ulf Zibis wrote: Hi Sherman, as I just said for 7183053, I can't look in the details at the moment, as I do not have suitable environment installed at the moment. Just one comment: I think it should be possible to share the mapping data partly across charsets, so the charsets.jar would be decreased again more? Yes, it might be desirable to share some of the mappings, especially among those variants. But as I suggested at the very beginning of the project, the priority for now is to move all the charsets to the new mapping based/build-time generated implementation, then it opens the door for new optimization, any improvement on those base classes and the generator tools (to share the mapping, for example) will be shared by all the sub-classes/classes. While it might be ideal to achieve all the goals at one shot, our resource restrict really does not allow me to spend most of my time on it (mapping re-generate really takes time and I have to test from various angles to make sure it does not break anything and not miss any corner case). This is more like a side-project (sure I do have a JEP for it but...) for now and I just found two spare weeks to push these two RFEs out. I might have more time on charsets later around the end development stage of JDK8. -Sherman -Ulf Am 16.07.2012 00:12, schrieb Xueming Shen: Hi This changeset includes the migration of our JIS0201/0208/0212 based single/ double-byte charsets to the new mapping based implementation. This is the left-over of the effort we put in JDK7 to re-implement most of our charsets in charsets.jar to (1)have better performance (2) small storage foot print and (3) ease the maintenance burden. http://cr.openjdk.java.net/~sherman/6653797/webrev/ Notes of the implementation: (1) jis0201/0208/0212 and their variants are now generated from the mapping table during the build time. (See those new .map *.nr and *.c2b tables) (2) EUC_JP/LINUX_OPEN, SJIS, PCK, ISO2022_JP and its variants are now using these new jis0201/02080212 charsets. (3) Those in red (in webrev) are the old implementation, since no charset uses them anymore, I removed them from the repository) (4) There are two approaches for PCK and SJIS. PCK.java_v1 and SJIS.java_v1 are the one that follows the old implementation, which decode/encodes base on the jis0201/0208 (and the variants) mapping via Ken's algorithm. This is known to be slow and buggy (the algothrim does not take care of illegal sjis cp, see #6653797 and http://cr.openjdk.java.net/~sherman/6653797/Sjis2Jis.java) So in this charset, I generated the direct mapping tables for sjis and pck and use the general DoubleByte base class for these two charsets. This results in much faster decoding/encoding and correct mapping for all code points. The downside of this approach is that it adds about 50k uncompressed side to the charsets.jar. But given this change actually reduces about 300K from the rt.jar, we still get a net 250K, so I decided to go with this approach for better performance. It appears to be lots of files (80+) in the webrev, but that number includes the removed old implementation and the tests I put in to guarantee the identical de/encoding result from the old and new implementations (those OLD... test cases), the change is actually not that big:-) So please help review. I can then put this multi-year efforts into rest. -Sherman
Re: Codereview request for 6653797: Reimplement JDK charset repository charsets.jar
Hi Sherman, as I just said for 7183053, I can't look in the details at the moment, as I do not have suitable environment installed at the moment. All I can see, looks reasonable. Regarding part 4 of bug 6653797, there is still existing adaptor from my side, if desired. Just one comment: I think it should be possible to share the mapping data partly across charsets, so the charsets.jar would be decreased again more? -Ulf Am 16.07.2012 00:12, schrieb Xueming Shen: Hi This changeset includes the migration of our JIS0201/0208/0212 based single/ double-byte charsets to the new mapping based implementation. This is the left-over of the effort we put in JDK7 to re-implement most of our charsets in charsets.jar to (1)have better performance (2) small storage foot print and (3) ease the maintenance burden. http://cr.openjdk.java.net/~sherman/6653797/webrev/ Notes of the implementation: (1) jis0201/0208/0212 and their variants are now generated from the mapping table during the build time. (See those new .map *.nr and *.c2b tables) (2) EUC_JP/LINUX_OPEN, SJIS, PCK, ISO2022_JP and its variants are now using these new jis0201/02080212 charsets. (3) Those in red (in webrev) are the old implementation, since no charset uses them anymore, I removed them from the repository) (4) There are two approaches for PCK and SJIS. PCK.java_v1 and SJIS.java_v1 are the one that follows the old implementation, which decode/encodes base on the jis0201/0208 (and the variants) mapping via Ken's algorithm. This is known to be slow and buggy (the algothrim does not take care of illegal sjis cp, see #6653797 and http://cr.openjdk.java.net/~sherman/6653797/Sjis2Jis.java) So in this charset, I generated the direct mapping tables for sjis and pck and use the general DoubleByte base class for these two charsets. This results in much faster decoding/encoding and correct mapping for all code points. The downside of this approach is that it adds about 50k uncompressed side to the charsets.jar. But given this change actually reduces about 300K from the rt.jar, we still get a net 250K, so I decided to go with this approach for better performance. It appears to be lots of files (80+) in the webrev, but that number includes the removed old implementation and the tests I put in to guarantee the identical de/encoding result from the old and new implementations (those OLD... test cases), the change is actually not that big:-) So please help review. I can then put this multi-year efforts into rest. -Sherman
Re: Codereview request for 6653797: Reimplement JDK charset repository charsets.jar
On 7/16/2012 9:57 AM, Ulf Zibis wrote: Hi Sherman, as I just said for 7183053, I can't look in the details at the moment, as I do not have suitable environment installed at the moment. All I can see, looks reasonable. Regarding part 4 of bug 6653797, there is still existing adaptor from my side, if desired. The sun.io has been removed. That will be an alternative if we hear any complain. Thanks! -Sherman Just one comment: I think it should be possible to share the mapping data partly across charsets, so the charsets.jar would be decreased again more? -Ulf Am 16.07.2012 00:12, schrieb Xueming Shen: Hi This changeset includes the migration of our JIS0201/0208/0212 based single/ double-byte charsets to the new mapping based implementation. This is the left-over of the effort we put in JDK7 to re-implement most of our charsets in charsets.jar to (1)have better performance (2) small storage foot print and (3) ease the maintenance burden. http://cr.openjdk.java.net/~sherman/6653797/webrev/ Notes of the implementation: (1) jis0201/0208/0212 and their variants are now generated from the mapping table during the build time. (See those new .map *.nr and *.c2b tables) (2) EUC_JP/LINUX_OPEN, SJIS, PCK, ISO2022_JP and its variants are now using these new jis0201/02080212 charsets. (3) Those in red (in webrev) are the old implementation, since no charset uses them anymore, I removed them from the repository) (4) There are two approaches for PCK and SJIS. PCK.java_v1 and SJIS.java_v1 are the one that follows the old implementation, which decode/encodes base on the jis0201/0208 (and the variants) mapping via Ken's algorithm. This is known to be slow and buggy (the algothrim does not take care of illegal sjis cp, see #6653797 and http://cr.openjdk.java.net/~sherman/6653797/Sjis2Jis.java) So in this charset, I generated the direct mapping tables for sjis and pck and use the general DoubleByte base class for these two charsets. This results in much faster decoding/encoding and correct mapping for all code points. The downside of this approach is that it adds about 50k uncompressed side to the charsets.jar. But given this change actually reduces about 300K from the rt.jar, we still get a net 250K, so I decided to go with this approach for better performance. It appears to be lots of files (80+) in the webrev, but that number includes the removed old implementation and the tests I put in to guarantee the identical de/encoding result from the old and new implementations (those OLD... test cases), the change is actually not that big:-) So please help review. I can then put this multi-year efforts into rest. -Sherman
Re: Codereview request for 6653797: Reimplement JDK charset repository charsets.jar
Am 16.07.2012 18:59, schrieb Xueming Shen: Yes, it might be desirable to share some of the mappings, especially among those variants. But as I suggested at the very beginning of the project, the priority for now is to move all the charsets to the new mapping based/build-time generated implementation, then it opens the door for new optimization, any improvement on those base classes and the generator tools (to share the mapping, for example) will be shared by all the sub-classes/classes. While it might be ideal to achieve all the goals at one shot, our resource restrict really does not allow me to spend most of my time on it (mapping re-generate really takes time and I have to test from various angles to make sure it does not break anything and not miss any corner case). This is more like a side-project (sure I do have a JEP for it but...) for now and I just found two spare weeks to push these two RFEs out. I might have more time on charsets later around the end development stage of JDK8. I totally agree, thanks. Hopefully I will have more time then. Sorry for the double-posting. The 2nd one has correct email for the list + one more text line. -Ulf
Re: Codereview request for 7183053: Optimize DoubleByte charset for String.getBytes()/new String(byte[])
Hi Alan, I gave the continue -else if a try, it appears the server vm obviously likes the continue approach (it is consistent with what we experienced in the past when we did similar approach for ascii, in which we separate/singled the ascii path out). So I guess we probably want to keep the continue here. Here are the data. dbcs2_new is to replace the continue with else if and the dbcs2 is the continue. http://cr.openjdk.java.net/~sherman/7183053/dbcs2_new http://cr.openjdk.java.net/~sherman/7183053/dbcs2 -Sherman On 07/13/2012 10:09 AM, Xueming Shen wrote: In JDK7, the decoder and encoder implementation of most of our single-byte charsets and UTF-8 charset are optimized to implement the internal interfce sun.nio.cs.ArrayDecoder/ Encoder to provide a fastpath for String.getBytes(...) and new String(byte[]...) operations. I have an old blog regarding this optimization at https://blogs.oracle.com/xuemingshen/entry/faster_new_string_bytes_cs This rfe, as the followup for above changes, is to implement ArrayDe/Encoder for most of the sun.nio.cs.ext.DoubleByte based double-byte charsets. Here is the webrev http://cr.openjdk.java.net/~sherman/7183053/webrev I've taken a pass over this and it's great to see DoubleByte.Decoder/Encoder implementing sun.nio.cs.ArrayDecoder/Encoder. The results looks good too, a small number of regressions (Big5 at len=32 for example) but this is a micro benchmark and I'm sure there are fluctuations. I don't see anything obviously wrong with the EBCDIC changes I'd need a history book to remember how the shifts between DBCS and SBCS. I think our tests our good for this area so I'm happy. One minor nit is the continue in both encode methods, I think it would be cleaner to use else if (bb ... instead. The continue might make the vm happy, but this is the code I did last Oct, so I might be wrong. Will give a couple run later with else
Re: Code Review Request: 7183800: TEST_BUG: Update tests to run on Ubuntu 12.04 (localhost is 127.0.1.1)
I just tried running these tests with -Djava.net.preferIPv4Stack set to true, but they still fail. I remember working on some of these failures in networking where ipv6 multicast was buggy, but absolutely nothing made those tests work. However, in this case, if we make sure that the address that the sender is sending the packets to and the address that the listener is binding to is the same, the tests are passing. The fix in this webrev is not working for Windows since the tests try to connect to 0.0.0.0. So we have to think of some other solution. - Kurchi On 7/16/2012 3:56 AM, Alan Bateman wrote: On 15/07/2012 19:54, Kurchi Subhra Hazra wrote: Hi, Some tests in our test repository assume that InetAddress.getLocalHost() will return 127.0.0.1. However, with linux systems running Ubuntu 12.04 now returning 127.0.1.1 as localhost, these tests are failing. I have changed two of the NIO tests to remove their dependency on InetAddress.getLocalHost(). A third test has been added to the ProblemList.txt since the changes required for it are more involved. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7183800 Webrev: http://cr.openjdk.java.net/~khazra/7183800/webrev.00/ As Chris pointed out, these tests bind to the wildcard address and you need a specific address to setup the address association, otherwise it's highly platform/implementation specific as to whether it will do as intended. So I think the proposed changes will cause problems where you can't connect to 0.0.0.0 and so I think we need to look for another solution. Given that none of the TCP tests fail then it suggests it mean that something else is going on, maybe something in the Ubuntu 12 configuration. Do these tests run if IPv6 is disabled? We've had issues with some distributions where multicast tests fail and these have always come down to iptables blocking IPv6 multicast packets causing the tests to fail. I just wonder if we have something similar here. -Alan -- -Kurchi
hg: jdk8/tl/jdk: 6880559: Enable PKCS11 64-bit windows builds
Changeset: 5cee646eaaa7 Author:vinnie Date: 2012-07-16 22:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5cee646eaaa7 6880559: Enable PKCS11 64-bit windows builds Reviewed-by: valeriep ! THIRD_PARTY_README ! make/sun/security/Makefile ! test/sun/security/pkcs11/PKCS11Test.java + test/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.chk + test/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/libnspr4.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/libnspr4.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/libplc4.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/libplc4.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/libplds4.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/libplds4.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/nss3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/nss3.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/nssckbi.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/nssdbm3.chk + test/sun/security/pkcs11/nss/lib/windows-amd64/nssdbm3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/nssutil3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/nssutil3.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.chk + test/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/sqlite3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/ssl3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/ssl3.lib + test/sun/security/pkcs11/nss/lib/windows-i586/freebl3.chk + test/sun/security/pkcs11/nss/lib/windows-i586/freebl3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.dll + test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.lib + test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.dll + test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.lib + test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.dll + test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.lib + test/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/nss3.lib + test/sun/security/pkcs11/nss/lib/windows-i586/nssckbi.dll + test/sun/security/pkcs11/nss/lib/windows-i586/nssdbm3.chk + test/sun/security/pkcs11/nss/lib/windows-i586/nssdbm3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/nssutil3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/nssutil3.lib + test/sun/security/pkcs11/nss/lib/windows-i586/softokn3.chk + test/sun/security/pkcs11/nss/lib/windows-i586/softokn3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/sqlite3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/ssl3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/ssl3.lib + test/sun/security/pkcs11/nss/src/MD5SUMS + test/sun/security/pkcs11/nss/src/SHA1SUMS + test/sun/security/pkcs11/nss/src/nss-3.13.1.tar.gz
hg: jdk8/tl: 6880559: Enable PKCS11 64-bit windows builds
Changeset: 0562a97bd601 Author:vinnie Date: 2012-07-16 22:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0562a97bd601 6880559: Enable PKCS11 64-bit windows builds Reviewed-by: valeriep ! THIRD_PARTY_README
Re: Code Review Request 7142596: RMI JPRT tests are failing
Here's webrev.05 (http://cr.openjdk.java.net/~dmocek/7142596/webrev.05). Changes: - Simplify createRegistryOnUnusedPort() - Simplify getUnusedRandomPort() - Add isReservedPort() method to determine if a port is a reserved port # (not just one of the FIXED_PORT's, but also any port which shouldn't be used). Passes all tests. Darryl On 07/16/2012 08:42 AM, Stuart Marks wrote: Hi Darryl, Sorry, I'm going to have to ask you to update this again. The issues are in TestLibrary.java and are all related to catching exceptions and throwing new exception instances, discarding the original exception (and probably relevant diagnostic information) in the process. Let's get together today and work on it. I expect it will take only half an hour or so to knock things out. s'marks On 7/13/12 1:40 PM, Darryl Mocek wrote: On 07/12/2012 05:13 PM, Stuart Marks wrote: OK, I took a look at the revised webrev. Most stuff is good. A couple changes are necessary though. *** MultipleRegistries.java Not a big deal, but the comment at lines 65-67 is no longer necessary. Comment removed. *** TestLibrary.java I think the reserved port range stuff still needs to be fixed up. The comment at lines 81-82 talks about a range 64000-64100 which isn't really present anywhere. The comment should instead say that PORT_MIN and PORT_MAX should be kept adjusted so that they specify the range of ports defined by the constants following. Make sure to do this adjustment; PORT_MAX is 64002 here. I reserved ports 64000-64100 (even though only 64001-64005 are currently being used) for fixed port tests (for tests which require fixed ports) so any future tests which require fixed ports can be assured there are ports available within a range for their use. In fixing the tests, I saw that those who wrote tests and used fixed ports grabbed random port numbers all over the place. Providing a reserved range allows them to just grab the next number and to keep the fixed port numbers in a group, even when new tests are added. If the ports are defined in a central place, like TestLibrary, then hopefully developers will come to TestLibrary to reserve the ports rather then define them in the tests themselves, like was done previously. I chose 100 ports for future-proofing...I don't think 100 is too many, but I've reduced it to 10 and lowered the max to 64010. I was also thinking of looking for tests which used fixed ports outside of RMI tests and standardizing those ports here, but that's possible future work and I'm not sure it's necessary. The previous webrev had PORT_MIN and PORT_MAX specify a range of 1024-64000 as the *allowed* range for ports returned by getUnusedRandomPort(). But as I described previously, this is difficult to enforce given the varying port allocation schemes on different OSes. Instead I think we need to invert the sense of the range PORT_MIN..PORT_MAX and make it be the range of ports reserved by tests that require fixed ports (64001 through 64005). Then, getUnusedRandomPort() needs to be changed to *disallow* ports in this range, that is, to retry if the port is within this range. Thus the condition on the while-loop has to be inverted, something like while (... unusedRandomPort = PORT_MIN unusedRandomPort = PORT_MAX) Yes, this is correct and it has been changed. So, how could getUnusedRandomPort() have worked in its present state? Well I think it ends up retrying 10 times, then at the end of the loop unusedRandomPort is actually some legal port number -- albeit possibly one within the disallowed range -- and almost certainly not -1, and so the method returns it and the caller uses it. So, the success-testing logic here will also have to change so that it retests whether the port is in the disallowed range. Correct...done. The comment on getUnusedRandomPort() also needs to be updated to reflect its new policy on the reserved range, as well as throwing an exception on failure. Also (nitpick) it should say less than not less then. Yes, I always do this. :( Looking at getUnusedRandomPort() again more closely [sorry] I think the catch of Exception that does nothing is suspicious. I'm not sure why getting a ServerSocket would fail, but if it does (maybe the system is out of ports??) we should just throw out to the caller. Perhaps ideally we'd just have this method throw IOException, but if that requires all callers to be updated, it might be easier just to catch IOException and throw a RuntimeException that wraps the caught IOException. I see no harm in trying again if it fails. If we have run out of ports, then possibly one or more used ports will be closed and freed and a subsequent try will succeed. I don't know all of the cases where a failure might occur. Anyway, if this is the prevailing way of handling this, I'll change it. Similar comments apply to the catch(Exception)/do-nothing code in the other utility methods. Now throwing
hg: jdk8/tl/jdk: 7177045: Rework the TestProviderLeak.java regression test, it is too fragile to low memory errors.
Changeset: 1469be7182b4 Author:khazra Date: 2012-07-16 16:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1469be7182b4 7177045: Rework the TestProviderLeak.java regression test, it is too fragile to low memory errors. Summary: Increase Xmx to 20 MB and add mechanisms to eat up most of the JVM free memory. Reviewed-by: wetmore Contributed-by: dan...@oracle.com ! test/com/sun/crypto/provider/KeyFactory/TestProviderLeak.java
hg: jdk8/tl/jdk: 7183203: ShortRSAKeynnn.sh tests intermittent failure
Changeset: e2d265c9b592 Author:weijun Date: 2012-07-17 11:28 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2d265c9b592 7183203: ShortRSAKeynnn.sh tests intermittent failure Reviewed-by: xuelei ! test/sun/security/mscapi/ShortRSAKey1024.sh - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh
hg: jdk8/tl/jdk: 7102106: TEST_BUG: sun/security/util/Oid/S11N.sh should be modified
Changeset: 2a39c98c1241 Author:weijun Date: 2012-07-17 11:57 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a39c98c1241 7102106: TEST_BUG: sun/security/util/Oid/S11N.sh should be modified Reviewed-by: mullan ! test/sun/security/util/Oid/S11N.sh
hg: jdk8/tl: 6 new changesets
Changeset: f6a685069274 Author:katleman Date: 2012-07-05 18:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f6a685069274 Added tag jdk8-b46 for changeset 27fa766a2298 ! .hgtags Changeset: c8d320b48626 Author:erikj Date: 2012-07-03 16:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c8d320b48626 7181504: Update of latest build-infra Makefiles Reviewed-by: ohair ! common/autoconf/autogen.sh ! common/autoconf/build-aux/config.guess ! common/autoconf/builddeps.conf.example ! common/autoconf/builddeps.m4 ! common/autoconf/configure ! common/autoconf/configure.ac - common/autoconf/cores.m4 ! common/autoconf/help.m4 ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! common/bin/compareimage.sh ! common/bin/diffexec.sh ! common/bin/diffjarzip.sh ! common/bin/difflib.sh ! common/makefiles/IdlCompilation.gmk ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/Makefile ! common/makefiles/NativeCompilation.gmk - common/makefiles/RMICompile.gmk Changeset: 3156dff953b1 Author:erikj Date: 2012-07-05 18:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3156dff953b1 7182051: Update of latest build-infra Makefiles (missing files) Reviewed-by: ohair + common/autoconf/basics.m4 + common/autoconf/boot-jdk.m4 + common/autoconf/build-aux/autoconf-config.guess + common/autoconf/build-performance.m4 + common/autoconf/generated-configure.sh + common/autoconf/jdk-options.m4 + common/autoconf/libraries.m4 + common/autoconf/source-dirs.m4 + common/autoconf/spec.sh.in + common/autoconf/toolchain.m4 + common/bin/compare-objects.sh ! common/makefiles/IdlCompilation.gmk + common/makefiles/MakeHelpers.gmk ! common/makefiles/NativeCompilation.gmk + common/makefiles/RMICompilation.gmk Changeset: 1dcb4b7b9373 Author:katleman Date: 2012-07-11 16:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1dcb4b7b9373 Merge - common/autoconf/cores.m4 - common/makefiles/RMICompile.gmk Changeset: aaae5471808d Author:katleman Date: 2012-07-12 16:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/aaae5471808d Added tag jdk8-b47 for changeset 1dcb4b7b9373 ! .hgtags Changeset: c88aceaf2f3f Author:lana Date: 2012-07-16 17:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c88aceaf2f3f Merge - common/autoconf/cores.m4 - common/makefiles/RMICompile.gmk
hg: jdk8/tl/corba: 3 new changesets
Changeset: cb31b67326bc Author:katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cb31b67326bc Added tag jdk8-b46 for changeset 30141e598d72 ! .hgtags Changeset: 21e46ea21c6a Author:lana Date: 2012-07-10 11:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/21e46ea21c6a Merge Changeset: 7e2b179a5b4d Author:katleman Date: 2012-07-12 16:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/7e2b179a5b4d Added tag jdk8-b47 for changeset 21e46ea21c6a ! .hgtags
hg: jdk8/tl/jaxws: 2 new changesets
Changeset: fe6a060afc40 Author:katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/fe6a060afc40 Added tag jdk8-b46 for changeset ae368a83c240 ! .hgtags Changeset: efb564de8a8e Author:katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/efb564de8a8e Added tag jdk8-b47 for changeset fe6a060afc40 ! .hgtags
hg: jdk8/tl/hotspot: 2 new changesets
Changeset: 0c7bb1f4f9c8 Author:katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0c7bb1f4f9c8 Added tag jdk8-b46 for changeset cf37a594c38d ! .hgtags Changeset: fa0c28fabbb1 Author:katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fa0c28fabbb1 Added tag jdk8-b47 for changeset 0c7bb1f4f9c8 ! .hgtags
hg: jdk8/tl/jaxp: 4 new changesets
Changeset: bf27b857c6ee Author:katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/bf27b857c6ee Added tag jdk8-b46 for changeset 300f45e99064 ! .hgtags Changeset: 404521944ac9 Author:lana Date: 2012-07-10 11:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/404521944ac9 Merge Changeset: 1c88da9a1365 Author:katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/1c88da9a1365 Added tag jdk8-b47 for changeset 404521944ac9 ! .hgtags Changeset: df4092828362 Author:lana Date: 2012-07-16 17:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/df4092828362 Merge
hg: jdk8/tl/langtools: 5 new changesets
Changeset: c7e62fc9df92 Author:katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c7e62fc9df92 Added tag jdk8-b46 for changeset 4ca599497172 ! .hgtags Changeset: 01d9911df25d Author:erikj Date: 2012-06-28 14:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/01d9911df25d 7180594: Fix GenStubs in langtools for build-infra builds Reviewed-by: ohair ! make/tools/genstubs/GenStubs.java Changeset: 7e6be2f239c9 Author:ohair Date: 2012-07-08 20:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7e6be2f239c9 Merge Changeset: afb0a5231557 Author:katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/afb0a5231557 Added tag jdk8-b47 for changeset 7e6be2f239c9 ! .hgtags Changeset: 1f8fc9e50a1f Author:lana Date: 2012-07-16 17:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1f8fc9e50a1f Merge
