Re: RFR (XXS) 8080535: (ch) Expected size of Character.UnicodeBlock.map is not optimal

On 16.05.2015 2:18, Martin Buchholz wrote: I don't think you're taking the load factor into account. Hm. You're right, HashMap's constructor expects the capacity as the argument. I was confused by IdentityHashMap, whose constructor expects the maximum number of elements to be inserted. ht

RFR(s): 8072726: add adapter to convert Enumeration to Iterator

Hi all, Please review this small API enhancement to add a default method "asIterator()" to Enumeration that converts it into an Iterator. Webrev: http://cr.openjdk.java.net/~smarks/reviews/8072726/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8072726 Thanks, s'ma

Re: JEP 254: Compact Strings

So, I'm pretty dubious, mostly because of the risks mentioned in the JEP. If you need a flag-check and two code paths for every String method, that's going to make the String class more slow and bloated, and make it very difficult for the JIT compiler to do its job inlining and intrinsifying calls

Re: RFR (XXS) 8080535: (ch) Expected size of Character.UnicodeBlock.map is not optimal

I don't think you're taking the load factor into account. https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/collect/Maps.java?r=f8144b4df7eec5f1c9e6942d8d5ef734a8767fd9#110 You want to check (via reflection) that the size of the backing array is unchanged if you co

RFR (XXS) 8080535: (ch) Expected size of Character.UnicodeBlock.map is not optimal

Hello! When constructing the map, the expected size is specified to be 256, but then 510 elements are inserted. A new whitebox test is provided, so the next time the number of entries grows, the expected size will not be forgotten. Would you please help review this fix? BUGURL: https://bugs.

Re: RFR(M,v3): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

Hi Dmitry, Peter, I should read my email more frequently - I missed Dmitry's last webrev email. My comments on a preference for volatile over Unsafe are not a strong objection to using Unsafe fences. I just don't have enough experience with Unsafe fences yet to agree that this use is correct

Re: RFR(M,v3): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

Hi Peter, Some comments below... On 5/14/15 3:50 AM, Peter Levart wrote: Hi Derek, On 05/13/2015 10:34 PM, Derek White wrote: Hi Peter, I don't have smoking gun evidence that your change introduces a bug, but I have some concerns... I did have a concern too, ... On 5/12/15 6:05 PM, Pet

Re: RFR(s): 8078463: optimize java/util/Map/Collisions.java

Go ahead and push. (Optimizing test runs is pretty important long term) On Thu, May 14, 2015 at 1:47 PM, Stuart Marks wrote: > On 5/14/15 1:22 AM, Daniel Fuchs wrote: > >> I'm curious: have you tried with using a lambda instead? changing: >> >> 394 static void check(String desc, boolean c

Re: RFR(M,v6): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

Everybody, Please review updated version. http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.06/ JDK part provided by Peter Levart, so all credentials belongs to him. -Dmitry On 2015-05-14 23:35, Peter Levart wrote: > > > On 05/14/2015 10:11 PM, Peter Levart wrote: >> Hi Dmitry, >> >>

Re: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java

Hi Brent, 1163 @Override 1164 public Enumeration keys() { 1165 return map.keys(); 1166 } I wonder if you should use: public Enumeration keys() { return Collections.enumeration(map.keySet()); } instead. ConcurrentHashMap.keys() returns an Enumeration which is also an It

Re: RFR 9: 8077350 Process API Updates Implementation Review

On Thu, May 14, 2015 at 6:44 AM, Roger Riggs wrote: > >> At some point in the development of this API, the implementation >> introduced the AsyncExecutor to execute synchronous continuations of the >> onExit() returned CompletableFuture(s). What was the main motivation for >> this given that: >>

Re: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java

On 5/13/15 8:53 AM, Mandy Chung wrote: On May 12, 2015, at 2:26 PM, Peter Levart wrote: On 05/12/2015 10:49 PM, Mandy Chung wrote: But I think it should be pretty safe to make the java.util.Properties object override all Hashtable methods and delegate to internal CMH so that: - all modification

Re: PriorityQueue

> > I was initially confused by this because it seems to attribute the > algorithmic difference to Comparable vs Comparator, which doesn't make any > sense That's exactly what threw me off as well, but I didn't bother checking (doh!). Anyway, I think the upside is we're all in agreement now that

Re: Review request for JDK-8078596: jaxp tests failed in modular jdk due to internal class access

Hi Frank, The patch looks good. I'll check it in later today. Thanks, Joe On 5/15/2015 8:35 AM, Lance Andersen wrote: Hi Frank, Seems OK Best Lance On May 15, 2015, at 5:48 AM, Frank Yuan > wrote: Hi, Joe and All This is a test bug on 9-repo-jigsaw, jaxp t

Re: PriorityQueue

Yes, this is very subtle, and Brett mentioned it (albeit somewhat obliquely) in an email on jdk9-dev: [1] If someone needs to make a heap and their data is Comparable, the corresponding constructor gives a O(n) runtime. If their data uses a Comparator, the corresponding runtime (using addAll)

RFR [9] 8080422: some docs cleanup for core libs

Hello, Could you please review the following fix http://cr.openjdk.java.net/~avstepan/8080422/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8080422 Just some HTML markup fix. The affected packages should (probably) not be visible in the new modular system, but nevertheless... Thank

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

I know injected fields are somewhat hacky, but there are a couple of conditions here which would motivate their use: 1. The field is of a type not known to Java. Usually, and in this case, it is a C pointer to some metadata. We can make space for it with a Java long, but that is a size mismatc

Re: PriorityQueue

Whoops, I believe you're right -- I completely overlooked that as well :( On Fri, May 15, 2015 at 12:40 PM, Paul Sandoz wrote: > > On May 15, 2015, at 6:15 PM, Louis Wasserman wrote: > > > http://lcm.csa.iisc.ernet.in/dsa/node139.html suggests an algorithm for > > heapifying an unsorted array i

Re: PriorityQueue

On May 15, 2015, at 6:15 PM, Louis Wasserman wrote: > http://lcm.csa.iisc.ernet.in/dsa/node139.html suggests an algorithm for > heapifying an unsorted array in O(n), corroborated elsewhere at > http://courses.csail.mit.edu/6.006/fall10/handouts/recitation10-8.pdf . > Any particular reason we can

Re: Patch to improve primitives Array.sort()

On May 15, 2015, at 11:48 AM, "Chan, Sunny" wrote: > I have provided Paul with an updated patch: > Here it is: http://cr.openjdk.java.net/~psandoz/tmp/gs/sort/webrev.1/ In DualPivotQuicksort 63 /** 64 * The maximum length of run in merge sort. 65 */ 66 private stat

Re: Review request for JDK-8078596: jaxp tests failed in modular jdk due to internal class access

Hi Frank, Seems OK Best Lance On May 15, 2015, at 5:48 AM, Frank Yuan wrote: > Hi, Joe and All > > > > This is a test bug on 9-repo-jigsaw, jaxp tests failed due to internal class > access. > > > > To fix this bug, I made the following changes: > > 1. moved the tests which test interna

RFR [9] 8072839: JAX-B Plugability Layer: using java.util.ServiceLoader

Hi everybody, this is review request for: 8072839: JAX-B Plugability Layer: using java.util.ServiceLoader The JAX-B API changed a little bit - proprietary ServiceLoader-like code has been replaced by java.util.ServiceLoader. This change is required by Jigsaw, old configuration way still suppor

Re: RFR: 8077846: improve locking strategy for readConfiguration(), reset(), and initializeGlobalHandlers()

On 05/05/15 08:19, Mandy Chung wrote: On 5/4/2015 11:52 AM, Daniel Fuchs wrote: On 04/05/15 16:46, Peter Levart wrote: Hi Daniel, Here it is: http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.04/ Looks good for me Peter :-) Hopefully Mandy will like it too! Yes

Re: PriorityQueue

Constructor has advantage in knowing it's working with a clean slate; addAll could check for that too, I suppose, and at least skip things like modCount increments. As a general rule of thumb, I always prefer to have dedicated methods for batch/bulk operations since you have more context to potent

Re: PriorityQueue

And/Or should PriorityQueue override addAll and provide a more performant implementation for common Collection types ( just like the constructor )? -Chris. On 15/05/15 14:20, Vitaly Davidovich wrote: Paul, I don't think you're missing anything obvious (unless I am as well :)). What you wrote

Re: RFR: 8061254: SPECjvm2008-XML performance regressions in 9-b33

On 2015-05-15 15:23, Alan Bateman wrote: On 13/05/2015 12:51, Claes Redestad wrote: Hi, 9-b33 introduced a sustained regression in SPECjvm2008 xml.transform on a number of our test setups. JDK-8058643 removed the check on value.length > 0, which means repeated calls to "".hashCode() now do a

Re: PriorityQueue

On May 15, 2015, at 3:20 PM, Vitaly Davidovich wrote: > Paul, > > I don't think you're missing anything obvious (unless I am as well :)). What > you wrote is basically what I meant by creating static helper method in > Brett's own code that does exactly what you wrote. The asymptotic comple

Re: RFR: 8061254: SPECjvm2008-XML performance regressions in 9-b33

On 13/05/2015 12:51, Claes Redestad wrote: Hi, 9-b33 introduced a sustained regression in SPECjvm2008 xml.transform on a number of our test setups. JDK-8058643 removed the check on value.length > 0, which means repeated calls to "".hashCode() now do a store of the calculated value (0) to the ha

Re: PriorityQueue

Paul, I don't think you're missing anything obvious (unless I am as well :)). What you wrote is basically what I meant by creating static helper method in Brett's own code that does exactly what you wrote. The asymptotic complexity will be nlogn in both cases, but the constant factor will be diff

Re: RFR: 8079459: JCK test api/java_nio/ByteBuffer/index.html#GetPutXXX start failing after JDK-8026049

On May 15, 2015, at 9:41 AM, Alan Bateman wrote: > > > On 14/05/2015 14:40, Andrew Haley wrote: >> >> >> : >> >> Fix: >> >> http://cr.openjdk.java.net/~aph/8079459-3-jdk/ >> >> Testcase: >> >> http://cr.openjdk.java.net/~aph/8079459-3-hs/ >> > This looks good to me. Saem here, Paul.

Re: PriorityQueue

On May 14, 2015, at 8:17 AM, Brett Bernstein wrote: > I believe the linked sequence of messages refer to the addition of a > PriorityQueue constructor only taking a Comparator which was does appear in > Java 1.8. Did you have a link to something regarding the a constructor > taking a Collection

Re: RFR 9: 8077350 Process API Updates Implementation Review

Hi Roger, On 05/15/2015 12:35 PM, Peter Levart wrote: public class AsyncCompletableFuture ... { /** * Returns a new CompletionStage that, when this stage completes * normally, completes with the given replacementResult. * * @param replacementResult the successful complet

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

After private discussion with Paul, here's an update: http://cr.openjdk.java.net/~vlivanov/8079205/webrev.03 Renamed CallSite$Context to MethodHandleNatives$Context. Best regards, Vladimir Ivanov On 5/14/15 3:18 PM, Vladimir Ivanov wrote: Small update in JDK code (webrev updated in place):

Re: RFR 9: 8077350 Process API Updates Implementation Review

Hi Roger, On 05/14/2015 03:44 PM, Roger Riggs wrote: Hi Peter, On 5/14/15 8:19 AM, Peter Levart wrote: Hi Roger, The new API using Optional(s) looks fine. In particular for the ProcessHandle returning methods. They now either return Stream or Optional. At some point in the development of

Review request for JDK-8078596: jaxp tests failed in modular jdk due to internal class access

Hi, Joe and All This is a test bug on 9-repo-jigsaw, jaxp tests failed due to internal class access. To fix this bug, I made the following changes: 1. moved the tests which test internal APIs to separate directory and added @modules for them 2. for other tests which don't intend to test i

RE: Patch to improve primitives Array.sort()

I have provided Paul with an updated patch: * The test has been updated using data provider and reduce as much repetition as possible. * The GS copyright notice from the main JDK patch. However we retain it on our test cases as we developed ourselves. In our previous contributions where we prov

Re: RFR: 8079459: JCK test api/java_nio/ByteBuffer/index.html#GetPutXXX start failing after JDK-8026049

On 15/05/15 08:41, Alan Bateman wrote: > his looks good to me. We'll need to address the splitting of the tests > between two repos at some point. Well, we did discuss it at the time. It wasn't clear what was being tested, the VM or the class library, and in the end the answer was "both". In th

Re: RFR: 8079459: JCK test api/java_nio/ByteBuffer/index.html#GetPutXXX start failing after JDK-8026049

On 14/05/2015 14:40, Andrew Haley wrote: : Fix: http://cr.openjdk.java.net/~aph/8079459-3-jdk/ Testcase: http://cr.openjdk.java.net/~aph/8079459-3-hs/ This looks good to me. We'll need to address the splitting of the tests between two repos at some point. -Alan.