Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-20 Thread Alan Bateman
On 19/02/2014 21:44, Brian Burkhalter wrote: This patch concerns cleaning up some ugly internal deprecations. Issue: https://bugs.openjdk.java.net/browse/JDK-8035279 Webrev: http://cr.openjdk.java.net/~bpb/8035279/webrev.00/ All JTREG BigInteger tests pass, and the serialized form has been

Re: JDK 9 RFR of JDK-8035076: Pattern$BnMS never used due to bug in Pattern$BnM.optimize

2014-02-20 Thread Alan Bateman
On 19/02/2014 22:31, Xueming Shen wrote: Hi, Please help codereview the change for JDK-8035076. Issue:https://bugs.openjdk.java.net/browse/JDK-8035076 Webrev: http://cr.openjdk.java.net/~sherman/8035067/webrev This is regression caused by the change we made back to jdk7 to support case

Re: RFR for JDK-8031563: TEST_BUG: java/nio/channels/Selector/ChangingInterests.java failed once

2014-02-20 Thread michael cui
On 02/18/2014 01:57 PM, michael cui wrote: Hi Alan, On 02/13/2014 08:15 PM, Alan Bateman wrote: I plan to look at this soon but I have a concern that it is changing the test so that the change from OP_READ to OP_READ|OP_WRITE no longer tests that the key is both readable and writable after

Re: RFR for JDK-8031563: TEST_BUG: java/nio/channels/Selector/ChangingInterests.java failed once

2014-02-20 Thread Alan Bateman
On 20/02/2014 08:33, michael cui wrote: Any chance to review the code? I will try to get back to you by early next week with suggestions. -Alan.

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-20 Thread Paul Sandoz
On Feb 20, 2014, at 9:13 AM, Alan Bateman alan.bate...@oracle.com wrote: On 19/02/2014 21:44, Brian Burkhalter wrote: This patch concerns cleaning up some ugly internal deprecations. Issue: https://bugs.openjdk.java.net/browse/JDK-8035279 Webrev:

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-20 Thread David Holmes
Hi Brian, On 20/02/2014 7:44 AM, Brian Burkhalter wrote: This patch concerns cleaning up some ugly internal deprecations. Issue: https://bugs.openjdk.java.net/browse/JDK-8035279 Webrev: http://cr.openjdk.java.net/~bpb/8035279/webrev.00/ All JTREG BigInteger tests pass, and the serialized

Re: Discussion on root cause analysis of JDK-7052625 : com/sun/net/httpserver/bugs/6725892/Test.java fails intermittently

2014-02-20 Thread David Holmes
Sounds like a question for net-dev more than core-libs - cc'd. David On 20/02/2014 4:11 PM, michael cui wrote: On 02/18/2014 12:51 AM, michael cui wrote: Hi, I would like to discuss my current root cause analysis of JDK-7052625 : com/sun/net/httpserver/bugs/6725892/Test.java fails

Re: Serial warnings in java.util.ArrayPrefixHelpers

2014-02-20 Thread Chris Hegarty
On 19 Feb 2014, at 23:44, Joseph Darcy joe.da...@oracle.com wrote: On 2/19/2014 12:16 PM, Martin Buchholz wrote: The jsr166 CVS version of this file already has serialVersionUIDs added. jsr166 CVS src/main has been jdk8/jdk9 warning-clean for a while now. Thanks for the update Martin;

RFR: 8032909: XSLT string-length returns incorrect length when string includes complementary chars

2014-02-20 Thread Aleksej Efimov
Hi, There is a problem in XSLT string-length function: When string passed to this function contains complementary chars the current implementation of XPath treates this sequence as two characters (the string-length returns 2). But according to the w3 spec it should be treated as a single

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-20 Thread Brian Burkhalter
On Feb 20, 2014, at 12:13 AM, Alan Bateman wrote: Are you sure there isn't any serialization impact? Zeros has also meant these are uninitialized so I just wonder about deserializing on an older JDK. I tested the following: 1) serialize with 9, deserialize with 7 2) serialize with 7,

Re: [9] RFR (M): 8027827: Improve performance of catchException combinator

2014-02-20 Thread Marcus Lagergren
This looks good, and we have done a significant number of test runs to verify its integrity. I say ship it. +1 We know that there are some issues with sun.misc.ValueConversion.castReference and similar internal methods not being inlined, but as far as I can understand this is a separate issue

Re: [9] RFR (M): 8027827: Improve performance of catchException combinator

2014-02-20 Thread Vladimir Ivanov
Thanks, Marcus! Best regards, Vladimir Ivanov On 2/20/14 7:31 PM, Marcus Lagergren wrote: This looks good, and we have done a significant number of test runs to verify its integrity. I say ship it. +1 We know that there are some issues with sun.misc.ValueConversion.castReference and

Re: [9] RFR (M): 8027827: Improve performance of catchException combinator

2014-02-20 Thread Paul Sandoz
Hi Vladimir, I know just enough about this area to be dangerous src/share/classes/java/lang/invoke/BoundMethodHandle.java 865 private static final SpeciesData[] SPECIES_DATA_CACHE = new SpeciesData[4]; Only 3 elements are stored in the above array?

Re: RFR - 6857566 (bf) DirectByteBuffer garbage creation can outpace reclamation

2014-02-20 Thread Peter Levart
On 02/05/2014 11:21 AM, Alan Bateman wrote: On 05/02/2014 08:08, Peter Levart wrote: Hi, I'm proposing a patch for the following issue: https://bugs.openjdk.java.net/browse/JDK-6857566 The patch is basically the same as developed and tested as part of the following discussion 3 months

Type of Class

2014-02-20 Thread Stephen Colebourne
In JDK 5, three methods were added to java.lang.Class [1] - isAnonymousClass() - isLocalClass() - isMemberClass() Unfortunately, these do not cover the complete range of possible types of class. Would it be reasonable to add the following methods: - isNestedClass() - isInnerClass() -

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-20 Thread Peter Levart
On 02/20/2014 11:20 AM, David Holmes wrote: Hi Brian, On 20/02/2014 7:44 AM, Brian Burkhalter wrote: This patch concerns cleaning up some ugly internal deprecations. Issue:https://bugs.openjdk.java.net/browse/JDK-8035279 Webrev:http://cr.openjdk.java.net/~bpb/8035279/webrev.00/ All

Re: [9] RFR (M): 8027827: Improve performance of catchException combinator

2014-02-20 Thread Vladimir Ivanov
Paul, Thanks for the feedback! See my answers inline. Updated webrev: http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.01/ I finally figured out how to make caching work. This webrev contains these changes. I changed LF representation a bit and added 2 auxiliary method handles -

Re: RFR: 8032909: XSLT string-length returns incorrect length when string includes complementary chars

2014-02-20 Thread huizhe wang
Hi Aleksej, The change looks good. It's good to consolidate test cases into a single test for each encoding. Thanks, Joe On 2/20/2014 6:54 AM, Aleksej Efimov wrote: Hi, There is a problem in XSLT string-length function: When string passed to this function contains complementary chars the

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-20 Thread Stuart Marks
On 2/20/14 9:55 AM, Peter Levart wrote: On 02/20/2014 11:20 AM, David Holmes wrote: re: volatile The basic approach being taken with these primitive fields is lazy initialization to a value that will always be the same if recomputed. If the variables are not volatile then in the worst-case

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-20 Thread David Holmes
Brian, Peter is absolutely right - I realized my mistake lying in bed last night. If the sentinel values were the default zero values there would be no issue but they are initialized to a different value. If the instances are then shared without a safe publication mechanism then it is

JDK 9 RFR of JDK-8035452: Fix serial lint warnings in core libs

2014-02-20 Thread Joe Darcy
Hello, Please review the patch below which will address the handful of remaining serial lint warning in the core libraries. Thanks, -Joe diff -r e5a09bc70308 src/share/classes/java/util/EnumSet.java --- a/src/share/classes/java/util/EnumSet.javaThu Feb 20 13:03:36 2014 + +++

Re: JDK 9 RFR of JDK-8035452: Fix serial lint warnings in core libs

2014-02-20 Thread Paul Benedict
Joe, I find it interesting that you suppressed the serial warning on an abstract class. I'd like to know more about that. Is this a universal rule? Are serial uids not important for abstract classes? On Thu, Feb 20, 2014 at 2:33 PM, Joe Darcy joe.da...@oracle.com wrote: Hello, Please review

JDK 9 RFR of JDK-8035453: Fix serial lint warnings in com.sun.tools and elsewhere

2014-02-20 Thread Joe Darcy
Hello, Please review my proposed changes for: JDK-8035453: Fix serial lint warnings in com.sun.tools and elsewhere http://cr.openjdk.java.net/~darcy/8035453.0/webrev/ -Joe --- old/src/share/classes/com/sun/java/browser/dom/DOMAccessException.java 2014-02-20 13:03:06.0 -0800

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-20 Thread Paul Sandoz
On Feb 20, 2014, at 9:09 PM, David Holmes david.hol...@oracle.com wrote: In practice, because there are also final fields in these instances implementations will most likely perform a storestore barrier after construction and prior to setting the reference to the created object. Yes, that is

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-20 Thread David Holmes
On 21/02/2014 7:20 AM, Paul Sandoz wrote: On Feb 20, 2014, at 9:09 PM, David Holmes david.hol...@oracle.com wrote: In practice, because there are also final fields in these instances implementations will most likely perform a storestore barrier after construction and prior to setting the

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-20 Thread Doug Lea
On 02/20/2014 05:11 PM, David Holmes wrote: On 21/02/2014 7:20 AM, Paul Sandoz wrote: On Feb 20, 2014, at 9:09 PM, David Holmes david.hol...@oracle.com wrote: In practice, because there are also final fields in these instances implementations will most likely perform a storestore barrier after

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-20 Thread John Rose
On Feb 20, 2014, at 12:09 PM, David Holmes david.hol...@oracle.com wrote: If the sentinel values were the default zero values there would be no issue This is an instance of the stable value pattern; see the javadoc for java/lang/invoke/Stable. Using zero for the sentinel in this pattern is

RFR(s): 8027810 RMI CheckUsage tests should be deleted

2014-02-20 Thread Stuart Marks
Hi all, There are a couple of RMI tests that do nothing except check the usage message emitted by the 'rmiregistry' and 'rmid' commands when given invalid command-line options. Since two bugs have occurred in these tests, I have determined that the overhead of maintaining these tests

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-20 Thread David Holmes
On 21/02/2014 9:52 AM, Doug Lea wrote: On 02/20/2014 05:11 PM, David Holmes wrote: On 21/02/2014 7:20 AM, Paul Sandoz wrote: On Feb 20, 2014, at 9:09 PM, David Holmes david.hol...@oracle.com wrote: In practice, because there are also final fields in these instances implementations will most

Re: RFR(s): 8027810 RMI CheckUsage tests should be deleted

2014-02-20 Thread Mandy Chung
Thumbs up. FYI - jdeps follows the langtools convention to define a static int run(String... args) method that doesn't exit but instead returns the error exit code (whereas the main method will exit with an error code) so that the test can test the tool with different options in the same VM

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-20 Thread David Holmes
On 21/02/2014 10:28 AM, John Rose wrote: On Feb 20, 2014, at 12:09 PM, David Holmes david.hol...@oracle.com mailto:david.hol...@oracle.com wrote: If the sentinel values were the default zero values there would be no issue This is an instance of the stable value pattern; see the javadoc for

Re: RFR(s): 8027810 RMI CheckUsage tests should be deleted

2014-02-20 Thread Stuart Marks
OK, thanks. Unfortunately I don't think the static int run() technique can be applied to rmiregistry and rmid, since a significant part of testing them -- apart from their usage messages :-) -- involves operating within a fairly strict security policy. But it's good to keep this in mind.

Re: [9] RFR (M): 8027827: Improve performance of catchException combinator

2014-02-20 Thread Marcus Lagergren
Got catches, Paul! /M On 20 Feb 2014, at 18:57, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: Paul, Thanks for the feedback! See my answers inline. Updated webrev: http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.01/ I finally figured out how to make caching work. This