Re: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass

2013-11-04 Thread Paul Sandoz
On Nov 2, 2013, at 10:03 AM, Alan Bateman alan.bate...@oracle.com wrote: On 01/11/2013 21:11, Mandy Chung wrote: I was expecting that would get optimized during runtime and it's a simple getter method. It's a good suggestion to cache it at the finalize thread start time and here is the

Re: RFR: JDK-8027796: Refactor Core Reflection for Type Annotations

2013-11-05 Thread Paul Sandoz
On Nov 4, 2013, at 8:36 PM, Joel Borggrén-Franck joel.fra...@oracle.com wrote: Hi Please review this small refactoring of the type annotations reflection code. This fix just makes the types final since the code wasn't designed for inheritance. webrev:

Re: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass

2013-11-05 Thread Paul Sandoz
On Nov 5, 2013, at 3:21 AM, Mandy Chung mandy.ch...@oracle.com wrote: 2. In VM.java. booted need not be volatile now that it is only accessed within a locked region. Also awaitBooted might as well be void as it can only ever return true. Fixed. Revised webrev at:

Re: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass

2013-11-05 Thread Paul Sandoz
On Nov 5, 2013, at 8:26 AM, Peter Levart peter.lev...@gmail.com wrote: P.S. I'm curious about the strange seemingly unneeded code fragments in FinalizerThread and both Runnables. For example: 169 forkSecondaryFinalizer(new Runnable() { 170*private volatile boolean running;* 171

Re: RFR 8027712 DistinctOpTest fails for unordered test

2013-11-05 Thread Paul Sandoz
On Nov 5, 2013, at 11:11 AM, Alan Bateman alan.bate...@oracle.com wrote: On 01/11/2013 17:57, Paul Sandoz wrote: Hi, This is a eating humble pie and should of correctly listened to Henry in review kind of email :-) The changes to DistinctOpTest recently committed result in a test

hg: jdk8/tl/jdk: 8027712: DistinctOpTest fails for unordered test

2013-11-05 Thread paul . sandoz
Changeset: d5b3f83ffc40 Author:psandoz Date: 2013-11-05 12:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5b3f83ffc40 8027712: DistinctOpTest fails for unordered test Reviewed-by: henryjen, alanb !

Re: RFR: JDK-8027645: Pattern.split() with positive lookahead

2013-11-11 Thread Paul Sandoz
On Nov 8, 2013, at 10:56 PM, Xueming Shen xueming.s...@oracle.com wrote: On 11/08/2013 01:19 AM, Paul Sandoz wrote: Hi Sherman. When you say: + * of the stream. A zero-width match at the beginning however never produces + * such empty leading substring. Is it possible

Re: Initial request for review of JDK-8006572 DoubleStream.sum()/average() implementations that reduce numerical errors

2013-11-18 Thread Paul Sandoz
Hi Joe, You can use the three arg form of collect for DoublePipeline.sum/average impls, which is already used for average: public final OptionalDouble average() { double[] avg = collect(() - new double[2], (ll, i) - {

Re: Building sorted Spliterators for library authors

2013-11-19 Thread Paul Sandoz
On Nov 19, 2013, at 4:50 PM, Louis Wasserman lowas...@google.com wrote: Is there a convenient way of building a Spliterator SORTED by a given Comparator, from, say, an array? Unfortunately not. There are no factory methods in j.u.Splitrerators that accept Comparator as a parameter, and as

Re: Initial request for review of JDK-8006572 DoubleStream.sum()/average() implementations that reduce numerical errors

2013-11-20 Thread Paul Sandoz
Hi Joe, On Nov 20, 2013, at 9:21 AM, Joe Darcy joe.da...@oracle.com wrote: Hi Paul, On 11/18/2013 07:38 AM, Paul Sandoz wrote: Hi Joe, You can use the three arg form of collect for DoublePipeline.sum/average impls, which is already used for average: public final OptionalDouble

RFR 8028516 Java doc error in Int/Long/Double/Stream.peek

2013-11-22 Thread Paul Sandoz
Hi, https://bugs.openjdk.java.net/browse/JDK-8028516 An attendee of the Devoxx lambda hackathon spotted some doc bugs in code samples of the stream peek methods. I updated those samples to be stand alone samples and verified they compile. Paul. diff -r 4bc37b6c4133

Re: Initial request for review of JDK-8006572 DoubleStream.sum()/average() implementations that reduce numerical errors

2013-11-25 Thread Paul Sandoz
+1 Paul. On Nov 23, 2013, at 8:06 AM, Joe Darcy joe.da...@oracle.com wrote: Hello Mike and Paul, Thanks for reviewing the earlier versions of the change; I've posted an update revision for your consideration at http://cr.openjdk.java.net/~darcy/8006572.4/ Two numerical aspects of

hg: jdk8/tl/jdk: 8028516: Java doc error in Int/Long/Double/Stream.peek

2013-11-25 Thread paul . sandoz
Changeset: 1f45b24ffe4b Author:psandoz Date: 2013-11-25 09:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1f45b24ffe4b 8028516: Java doc error in Int/Long/Double/Stream.peek Reviewed-by: chegar ! src/share/classes/java/util/stream/DoubleStream.java !

Re: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method

2013-11-25 Thread Paul Sandoz
HI David, Just curious: why did you chose to add the method, throwIllegalAccessError, to s.m.Unsafe and add Unsafe to the list pre-loaded classes rather than modifying an existing pre-loaded class? Paul.

RFR 8029164: Race condition in CompletableFuture.thenCompose with asynchronous task

2013-11-27 Thread Paul Sandoz
Hi, https://bugs.openjdk.java.net/browse/JDK-8029164 http://cr.openjdk.java.net/~psandoz/tl/JDK-8029164-thenCompose-async/webrev/ This fixes an issue with CompletableFuture.thenCompose. If the composing future is already completed before the call to thenCompose (or completes during some

8028564: Concurrent calls to CHM.put can fail to add the key/value to the map

2013-12-02 Thread Paul Sandoz
Hi, http://cr.openjdk.java.net/~psandoz/tl/JDK-8028564-concurrent-resize/webrev/ This patch is contributed by Doug Lea and fixes two issues found in ConcurrentHashMap: 1) A problem with concurrent resizes; and 2) The skipping of elements when traversing through bins that are trees of

hg: jdk8/tl/jdk: 8029164: Race condition in CompletableFuture.thenCompose with asynchronous task

2013-12-04 Thread paul . sandoz
Changeset: 2aa455506c49 Author:psandoz Date: 2013-12-04 10:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2aa455506c49 8029164: Race condition in CompletableFuture.thenCompose with asynchronous task Reviewed-by: dl, chegar, mduigou !

Re: 8028564: Concurrent calls to CHM.put can fail to add the key/value to the map

2013-12-04 Thread Paul Sandoz
I have reviewed Doug's code, just need someone to quickly review the test code. Paul. On Dec 2, 2013, at 5:29 PM, Paul Sandoz paul.san...@oracle.com wrote: Hi, http://cr.openjdk.java.net/~psandoz/tl/JDK-8028564-concurrent-resize/webrev/ This patch is contributed by Doug Lea and fixes two

hg: jdk8/tl/jdk: 8028564: Concurrent calls to CHM.put can fail to add the key/value to the map

2013-12-05 Thread paul . sandoz
Changeset: dc2f0c40399a Author:psandoz Date: 2013-12-05 09:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dc2f0c40399a 8028564: Concurrent calls to CHM.put can fail to add the key/value to the map Reviewed-by: psandoz, chegar, alanb Contributed-by: Doug Lea

Re: RFR: 8029451 : Tidy warnings cleanup for java.util package

2013-12-05 Thread Paul Sandoz
On Dec 5, 2013, at 6:30 AM, Sergey Lugovoy sergey.lugo...@oracle.com wrote: Hi all, please review the fix http://cr.openjdk.java.net/~yan/8029451/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8029451 This patch cleanup tidy warnings for generated html documentation, and do not

Re: 8028564: Concurrent calls to CHM.put can fail to add the key/value to the map

2013-12-06 Thread Paul Sandoz
On Dec 5, 2013, at 9:29 PM, Doug Lea d...@cs.oswego.edu wrote: On 12/05/2013 03:18 PM, Brent Christian wrote: I'm curious about why this was done: *** 4452,4462 public final boolean removeAll(Collection? c) { ! Objects.requireNonNull(c); boolean

Re: RFR: 8029696 : (xs) Broken doc links to package-summary.html#NonInterference in java.util.stream

2013-12-09 Thread Paul Sandoz
On Dec 6, 2013, at 8:59 PM, Mike Duigou mike.dui...@oracle.com wrote: Hello all; https://bugs.openjdk.java.net/browse/JDK-8029696 Michael McMahon noticed that some links to the anchor #NonInterference were not using the correct name for the anchor. He prepared a patch which I

Re: Map.forEach

2013-12-10 Thread Paul Sandoz
On Dec 10, 2013, at 5:14 AM, Martin Buchholz marti...@google.com wrote: Hmmm... it was time that I studied Map.forEach I see you convert to ISE to CME ... (Synchronized maps (like Hashtable) do not implement ConcurrentMap. Is that a bug?) Imagine a third party implementation of a

Re: RFR: 8029795 : LinkedHashMap.getOrDefault() doesn't update access order. (was Why doesn't new Map methods generate entry accesses on LinkedHashMap?)

2013-12-11 Thread Paul Sandoz
On Dec 11, 2013, at 1:27 AM, Mike Duigou mike.dui...@oracle.com wrote: I have added tests and documentation for the other methods. http://cr.openjdk.java.net/~mduigou/JDK-8029795/1/webrev/ The documentation for some of the methods is ambiguous about how many access events are generated.

Re: RFR: 8030016: HashMap.computeIfAbsent generates spurious access event

2013-12-13 Thread Paul Sandoz
On Dec 12, 2013, at 6:24 AM, Mike Duigou mike.dui...@oracle.com wrote: Hello all; In the review for JDK-8029795 Paul Sandoz noted that HashMap.computeIfAbsent would generate a spurious access event for keys mapped to null when the function returned null. This patch corrects

RFR of lang level code migration patches

2013-12-19 Thread Paul Sandoz
Hi, Here are some patches that migrate some code to use more up to date language features. I will create a bug later on after feedback. This is motivated from Brian's patches to lang tools. I focused just on java.util, minus the concurrent packages, and i used the IDE to assist in the code

Re: Bug in Long.parseUnsignedLong

2013-12-19 Thread Paul Sandoz
Hi, I think the logic for overflow when using the compareUnsigned is incorrect in Long: long first = parseLong(s.substring(0, len - 1), radix); int second = Character.digit(s.charAt(len - 1), radix); if (second 0) { throw new

Re: RFR of lang level code migration patches

2013-12-20 Thread Paul Sandoz
On Dec 19, 2013, at 5:44 PM, Brian Goetz brian.go...@oracle.com wrote: +1 on all changes, except perhaps for this one in Collections.copy: ListIterator? super T di=dest.listIterator(); ListIterator? extends T si=src.listIterator(); for (int i=0; isrcSize; i++) {

Re: Bug in Long.parseUnsignedLong

2013-12-20 Thread Paul Sandoz
Hi Brian, It would be nice to avoid the caches, on a hunch i am wondering if the following will work: long result = first * radix + second; if ((first 1) (Long.MAX_VALUE / radix) || // possible overflow of first * radix Long.compareUnsigned(result, first) 0) { // overflow of

Re: Demo for Parallel Core Collection API

2013-12-20 Thread Paul Sandoz
Hi Tristan, Thanks, I need to look at this in more detail, but here are some quick comments. - recommend you try and avoid using limit with parallel ops, for example the Pi example cam be reformulated as: long M = LongStream.range(0, N).parallel().filter(sr - { double x =

RFR 8031187: DoubleStream.count is incorrect for a stream containing Integer.MAX_VALUE elements

2014-01-06 Thread Paul Sandoz
Hi, Please review the following which fixes an embarrassing bug in DoubleStream.count: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8031187-DoubleStream-count/webrev/ I included a test CountLargeTest that counts up to Integer.MAX_VALUE + 1. On my mac book this takes about 27s to run from

Re: JDK 9 RFR of raw type lint fix to java.lang.management

2014-01-07 Thread Paul Sandoz
+1 Paul. On Jan 7, 2014, at 9:30 PM, Joe Darcy joe.da...@oracle.com wrote: Hello, Please review another minor lint fix of a raw type issues in the core libraries: diff -r 2647b91dbc2a src/share/classes/java/lang/management/ManagementFactory.java ---

Re: JDK 9 RFR of 8030814: Long.parseUnsignedLong should throw exception on too large input

2014-01-09 Thread Paul Sandoz
Hi Brian, This generally looks good, rather clever trick, i prefer it to using a cache. I agree with Joe some comments are required as it is not immediately obvious how this works. The additional tests seem adequate (overflow of the overflow), it's easy to go overboard e.g. you could test:

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

2014-01-09 Thread Paul Sandoz
On Jan 9, 2014, at 10:52 AM, Tristan Yan tristan@oracle.com wrote: Can someone else give a second review on this. In a comment the bug you state: here total_turns_taken is a static variable, it could affect by other tests I don't quite know under what test circumstances that can

hg: jdk8/tl/jdk: 8031187: DoubleStream.count is incorrect for a stream containing Integer.MAX_VALUE elements

2014-01-09 Thread paul . sandoz
Changeset: 630a92015993 Author:psandoz Date: 2014-01-09 10:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/630a92015993 8031187: DoubleStream.count is incorrect for a stream containing Integer.MAX_VALUE elements Reviewed-by: darcy !

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

2014-01-09 Thread Paul Sandoz
On Jan 9, 2014, at 12:07 PM, Tristan Yan tristan@oracle.com wrote: Thank you Paul I change turn to local variable as well. http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.03/ I am not sure I understand your second suggestion here, sum up thread_turns of each Context(This is

RFR 8031428 CountTest causes lambda Ser/Derialization tests to fail

2014-01-10 Thread Paul Sandoz
Hi, A small tweak is required to a recent Stream-based test i added to stop some internal lambda-based ser/derialization (SAND) tests barfing since the test is hostile to ser/derialization, and infact i should have probably written the test like below in the first place. Kumar has verified it

RFR 8030848: Collections.sort(List l, Comparator) should defer to List.sort(Comparator )

2014-01-10 Thread Paul Sandoz
Hi, When we added the List.sort method the default implementation deferred to Collections.sort. This is the wrong way around, since any existing use of Collections.sort say with ArrayList will not avail of the optimal implementation provided by ArrayList.sort. To resolve this the

Re: RFR 8031428 CountTest causes lambda Ser/Derialization tests to fail

2014-01-10 Thread Paul Sandoz
On Jan 10, 2014, at 12:48 PM, Chris Hegarty chris.hega...@oracle.com wrote: Looks fine to me. Thanks. I don't think AtomicLong was ever needed here. It was crudely used as a holder of the count, since captured refs are (effectively) final, and not for it's concurrent properties as i

RFR 8029452: Fork/Join task ForEachOps.ForEachOrderedTask clarifications and minor improvements

2014-01-10 Thread Paul Sandoz
Hi, Some tweaks to the Stream forEachOrdered operation: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8029452-ForEachOrdered/webrev/ The first tweak is to size the CHM used in ForEachOrderedTask, this avoids concurrent resizes and the costs associated with those. The second tweak is to

Re: RFR 8029452: Fork/Join task ForEachOps.ForEachOrderedTask clarifications and minor improvements

2014-01-10 Thread Paul Sandoz
On Jan 10, 2014, at 7:11 PM, Mike Duigou mike.dui...@oracle.com wrote: The second tweak is to consolidate the reporting of elements to within the ForEachOrderedTask.tryComplete method. I have also removed the inconsistently applied synchronized block. Either we apply it consistently to

Re: RFR 8030848: Collections.sort(List l, Comparator) should defer to List.sort(Comparator )

2014-01-13 Thread Paul Sandoz
On Jan 10, 2014, at 6:56 PM, Mike Duigou mike.dui...@oracle.com wrote: The implementation looks good. I would move construction of the listIterator to before the toArray() for detection of concurrent modification (growing of the list). If there is another thread concurrently operating on

Doc updates was Re: RFR 8030848: Collections.sort(List l, Comparator) should defer to List.sort(Comparator )

2014-01-13 Thread Paul Sandoz
On Jan 10, 2014, at 3:01 PM, Alan Bateman alan.bate...@oracle.com wrote: The implementation changes look good. I agree that the javadoc needs changing as it's otherwise misleading as to what the implementation actually does. I would think that this should go with the implementation change

Re: Demo for Parallel Core Collection API

2014-01-14 Thread Paul Sandoz
more complex is the rendering of the Mandelbrot set, parallelized along the real or imaginary axis. Once can easily generate some nice ASCII-like art :-) Paul. On Dec 20, 2013, at 6:25 PM, Paul Sandoz paul.san...@oracle.com wrote: Thanks, I need to look at this in more detail, but here are some

Re: JDK 9 RFR of 8030814: Long.parseUnsignedLong should throw exception on too large input

2014-01-15 Thread Paul Sandoz
On Jan 14, 2014, at 8:56 PM, Brian Burkhalter brian.burkhal...@oracle.com wrote: Please see the updated webrev http://cr.openjdk.java.net/~bpb/8030814/webrev.3/. Hopefully my verbose description of the very clever overflow test is accurate and understandable. Also, I cleaned up the

Re: RFR 8029452: Fork/Join task ForEachOps.ForEachOrderedTask clarifications and minor improvements

2014-01-16 Thread Paul Sandoz
On Jan 10, 2014, at 2:42 PM, Paul Sandoz paul.san...@oracle.com wrote: I have also removed the inconsistently applied synchronized block. Either we apply it consistently to reporting or not at all. It was originally there because we were not sure that the happens-before relationship [1

Re: JDK 9 RFC on 6667086: Double.doubleToLongBits(final double value) contains inefficient test for NaN

2014-01-16 Thread Paul Sandoz
On Jan 15, 2014, at 10:28 PM, Brian Burkhalter brian.burkhal...@oracle.com wrote: Issue:https://bugs.openjdk.java.net/browse/JDK-6667086 Webrev: http://cr.openjdk.java.net/~bpb/6667086/webrev/ According to micro-benckmarks, there is no statistically significant performance

Re: Review request for JDK-6760902: inconsistent behavior in bootstrap class loader for classes and resources

2014-01-16 Thread Paul Sandoz
On Jan 16, 2014, at 2:27 AM, Mandy Chung mandy.ch...@oracle.com wrote: There is an inconsistency in searching classes vs resources if bootclasspath contains an empty path. Empty path on bootclasspath is skipped by the bootstrap class loader when searching classes while it defaults to

Re: Review request for JDK-6760902: inconsistent behavior in bootstrap class loader for classes and resources

2014-01-16 Thread Paul Sandoz
On Jan 16, 2014, at 4:51 PM, Mandy Chung mandy.ch...@oracle.com wrote: On 1/16/2014 7:39 AM, Paul Sandoz wrote: On Jan 16, 2014, at 2:27 AM, Mandy Chung mandy.ch...@oracle.com wrote: There is an inconsistency in searching classes vs resources if bootclasspath contains an empty path

Re: RFR: JDK-8031373 and 8030079 -- lint warnings in java.util.stream and java.lang.invoke

2014-01-17 Thread Paul Sandoz
On Jan 17, 2014, at 5:09 PM, Brian Goetz brian.go...@oracle.com wrote: Webrev at: http://cr.openjdk.java.net/~briangoetz/JDK-8031373/webrev/ If someone with ASM fu (Remi?) could sanity check the JLI changes, that would be appreciated. Stream code looks good. I notice some other

Re: Review request for JDK-6760902: inconsistent behavior in bootstrap class loader for classes and resources

2014-01-20 Thread Paul Sandoz
On Jan 17, 2014, at 10:10 PM, Mandy Chung mandy.ch...@oracle.com wrote: Paul, Here is the updated webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6760902/webrev.01/ This cleans up GetResource.sh and merges with GetResource2.sh. Also fixed if (pos - lastPoc 0) line and javadoc

Re: RFR: 8032190 It's unclear that flatMap will ensure each stream will be closed.

2014-01-20 Thread Paul Sandoz
On Jan 20, 2014, at 3:18 PM, Chris Hegarty chris.hega...@oracle.com wrote: It is good to clarify that the streams are closed. I find the following updated wording a little odd, If a mapped stream is {@code null} then it treated as if it was an empty stream. I thought the previous wording

Re: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement

2014-01-20 Thread Paul Sandoz
On Jan 16, 2014, at 7:08 PM, Xueming Shen xueming.s...@oracle.com wrote: Hi, The proposed changeset is to improve the performance (both speed and memory usage) of String.toLowerCase/toUpperCase, by (1) to separate the most likely use scenario (non supplementary character, no special

Re: RFR: 8032190 It's unclear that flatMap will ensure each stream will be closed.

2014-01-21 Thread Paul Sandoz
On Jan 20, 2014, at 11:16 PM, Alan Bateman alan.bate...@oracle.com wrote: On 20/01/2014 10:38, Paul Sandoz wrote: Hi, For the flatMap operations of streams we forgot to say what it does with the mapped streams after it has processed them i.e. closes them, which is important for I/O

Re: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement

2014-01-22 Thread Paul Sandoz
On Jan 21, 2014, at 11:05 PM, Xueming Shen xueming.s...@oracle.com wrote: Hi Paul, thanks for reviewing the changeset, comment inlined below. On 01/20/2014 09:24 AM, Paul Sandoz wrote: Some quick comments. In String.toLowerCase: - it would be nice to get rid of the pseudo goto using

hg: jdk8/tl/jdk: 8032190: Specifications of stream flatMap methods should require mapped streams to be closed

2014-01-23 Thread paul . sandoz
Changeset: 68eb0c55a8c0 Author:psandoz Date: 2014-01-21 10:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68eb0c55a8c0 8032190: Specifications of stream flatMap methods should require mapped streams to be closed Reviewed-by: chegar, alanb !

Re: 8032456: vm/jni/Miscellaneous/misc001/misc00101m1/misc00101m1.html failing on OS X

2014-01-24 Thread Paul Sandoz
On Jan 24, 2014, at 12:00 PM, Alan Bateman alan.bate...@oracle.com wrote: I need a reviewer to fix an issue with the changes in JDK 8 to support statically linked JNI libraries. The issue arises with tests that have both JNI_OnLoad and JNI_OnLoad_libname functions defined, and code

Survey on sun.misc.Unsafe

2014-01-24 Thread Paul Sandoz
Hi, We are gathering feedback on sun.misc.Unsafe usage. If you have ever used it please consider taking this survey and helping us out: https://www.surveymonkey.com/s/sun-misc-Unsafe -- We also plan to trawl stuff on repos. I have done a selective bit of that already, running with a little

Re: RFR: Update code in java.lang to use new language features

2014-01-24 Thread Paul Sandoz
for anyone else who wants to have a go on other packages :-) Paul. On Jan 24, 2014, at 6:02 PM, Alan Bateman alan.bate...@oracle.com wrote: On 24/01/2014 14:45, Paul Sandoz wrote: -- http://cr.openjdk.java.net/~psandoz/jdk9/java.lang-StringBuilder/ -- http://cr.openjdk.java.net/~psandoz

Re: RFR: 8022854 : (s) Cleaner re-initialization of System properties

2014-01-28 Thread Paul Sandoz
Hi Mike, Your patch is slightly out of sync with 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c8c4f441fc76 http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/src/share/classes/sun/misc/VM.java -- Generally looks OK. Bikeshed-wise i prefer something like getPublicSavedProperties rather

Re: RFR(s): 8023541 Race condition in rmid initialization

2014-01-29 Thread Paul Sandoz
On Jan 29, 2014, at 10:29 AM, Alan Bateman alan.bate...@oracle.com wrote: I just wonder if you could change initialized to volatile and only synchronize/wait when false? That way you would only be adding a read of a volatile. I assume the stub can never be null so maybe it could be changed

Re: RFR(s): 8023541 Race condition in rmid initialization

2014-01-30 Thread Paul Sandoz
On Jan 30, 2014, at 3:57 AM, Stuart Marks stuart.ma...@oracle.com wrote: Then, awaitInitialized seems straightforward until you see that the condition is waiting for the value of a final variable to change! JLS sec 17.5 [1] allows all sorts of optimizations for final fields, but they all

Re: [8] RFR (S): 8033278: Missed access checks for Lookup.unreflect* after 8032585

2014-01-31 Thread Paul Sandoz
On Jan 31, 2014, at 1:58 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: http://cr.openjdk.java.net/~vlivanov/8033278/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8033278 The fix for 8032585 [1] introduced a regression: in some cases access check on a reference class is

hg: jdk8/tl/jdk: 4 new changesets

2014-01-31 Thread paul . sandoz
Changeset: 9f098aed44c0 Author:anazarov Date: 2014-01-31 12:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f098aed44c0 8032025: Update repeating annotations demo Reviewed-by: jfranck + src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Device.java

Re: RFR(s): 8023541 Race condition in rmid initialization

2014-01-31 Thread Paul Sandoz
On Jan 30, 2014, at 11:02 PM, Stuart Marks stuart.ma...@oracle.com wrote: Maybe. I'd guess that the new JMM will stick to covering well-behaved programs (e.g. ones that adhere to safe publication). The difficulty with issues like this one is that once publication has occurred unsafely, we

Re: [8] RFR (S): 8033278: Missed access checks for Lookup.unreflect* after 8032585

2014-01-31 Thread Paul Sandoz
On Jan 31, 2014, at 3:21 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: Paul, The transformation you suggest is equivalent, but I reluctant to apply it. IMO, it doesn't add much value and current version is easier to read. OK, i guess we will just have to agree to disagree on

Re: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList does not validate range properly

2014-01-31 Thread Paul Sandoz
On Jan 31, 2014, at 5:23 PM, Chris Hegarty chris.hega...@oracle.com wrote: Trivial change to CopyOnWriteArrayList.COWSubList.subList to catch the case where the fromIndex is greater that the toIndex. http://cr.openjdk.java.net/~chegar/8011645/webrev.00/webrev/ Looks ok to me. -- Shame

Re: JDK 9 RFR of JDK-8033416: Remove sun.misc.FpUtils

2014-02-03 Thread Paul Sandoz
On Feb 1, 2014, at 10:23 PM, Alan Bateman alan.bate...@oracle.com wrote: On 01/02/2014 18:13, Joe Darcy wrote: Hello, Back in JDK 5, the sun.misc.FpUtils class was added to provide low-level floating-point manipulations methods needed to write tests of the math library. Over time, those

Re: Demo for Parallel Core Collection API

2014-02-04 Thread Paul Sandoz
On Feb 4, 2014, at 2:58 AM, Tristan Yan tristan@oracle.com wrote: Hi Paul I know this may be a little bit late. Yes, likely too late... (see below). But I am still asking you review this. http://cr.openjdk.java.net/~tyan/JDK-8033358/webrev.01/ This is a whole demo code include the

Re: ObjectIn/OutputStream improvements

2014-02-04 Thread Paul Sandoz
On Feb 3, 2014, at 11:01 PM, Stuart Marks stuart.ma...@oracle.com wrote: Nobody took the bait on this yet? :-) Certainly there's a lot of semi-myth on this topic, on both sides. Here's my source of mythology (or urban legend, as one might have it):

Re: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement

2014-02-05 Thread Paul Sandoz
On Feb 5, 2014, at 6:58 PM, Xueming Shen xueming.s...@oracle.com wrote: Hi, Let's try to wrap it up, otherwise I may drop the ball somewhere :-) On 01/22/2014 07:20 AM, Paul Sandoz wrote: if (lang == tr || lang == az || lang == lt) { // local dependent return toLowerCaseEx

Re: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement

2014-02-06 Thread Paul Sandoz
On Feb 6, 2014, at 5:37 AM, Xueming Shen xueming.s...@oracle.com wrote: Fair enough. I don't think it's going to be a measurable difference. I have updated the webrev to use the Character.isSurrogate() for better readability. http://cr.openjdk.java.net/~sherman/8032012/webrev One last

Re: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement

2014-02-07 Thread Paul Sandoz
On Feb 6, 2014, at 6:40 PM, Xueming Shen xueming.s...@oracle.com wrote: Paul, toUpperCaseEx is overridden in CharacterData00/Latin1. Those two are under gensrc/java/lang. It might be possible to combine them some day (need to dig out some decade long history and probably there is

Re: Draft JEP on enhanced volatiles

2014-02-10 Thread Paul Sandoz
On Feb 9, 2014, at 1:52 PM, Remi Forax fo...@univ-mlv.fr wrote: On 02/08/2014 06:52 PM, Brian Goetz wrote: can you be a little more specific and provide the way foo.volatile.compareAndSet is compiled with this example: Hey, the JEP isn't even out of draft yet! Stop asking hard questions.

Re: Time to remove sun.misc.Service?

2014-02-11 Thread Paul Sandoz
On Feb 11, 2014, at 12:19 PM, Alan Bateman alan.bate...@oracle.com wrote: It was never meant to be used by anything outside of the JDK and there has been a standard API (java.util.ServiceLoader) since JDK 6 (released in 2006). Scrub it! AFAICT it is not widely used (looking at the use of

Re: methods that throws checked exceptions in a lambda block

2014-02-12 Thread Paul Sandoz
On Feb 12, 2014, at 4:05 PM, Wang Weijun weijun.w...@oracle.com wrote: This line does not compile Files.list(Paths.get(/secret)).forEach(x - Files.write(x, new byte[Files.size(x)]); because Files.write() and Files.size() throw IOE. Then what's the best way to make it work? It

Re: Why isEmpty(), retainAll() and containsAll() not supported with default implementations in JDK8?

2014-02-14 Thread Paul Sandoz
On Feb 14, 2014, at 2:13 PM, Roman Leventov leven...@ya.ru wrote: I'm sure there was a discussion somewhere in JDK mailing lists, but I couldn't find. Please, give me a link. I cannot recall such discussion. Generally we have only converted existing abstract methods on an interface to

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: [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: 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-21 Thread Paul Sandoz
On Feb 21, 2014, at 12:52 AM, Doug Lea d...@cs.oswego.edu 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

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

2014-02-21 Thread Paul Sandoz
On Feb 20, 2014, at 6:57 PM, 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 webrev contains

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

2014-02-24 Thread Paul Sandoz
Hi Joe, On Feb 20, 2014, at 10:14 PM, Joe Darcy joe.da...@oracle.com wrote: 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/ Looks good. I agree with Paul B.

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

2014-02-25 Thread Paul Sandoz
On Feb 25, 2014, at 1:32 AM, Brian Burkhalter brian.burkhal...@oracle.com wrote: On Feb 20, 2014, at 6:39 PM, David Holmes wrote: Not clear what you mean by this. This is more or less my reaction to this entire thread, so to speak. ;-) Anyway, thanks for all the comments. :-)

Re: RFR 8027640 : String.indexOf(String, int) for the empty string case not specified

2014-02-25 Thread Paul Sandoz
On Feb 25, 2014, at 12:52 AM, Brent Christian brent.christ...@oracle.com wrote: Please review my changes for: https://bugs.openjdk.java.net/browse/JDK-8027640 The webrev is here: http://cr.openjdk.java.net/~bchristi/8027640/webrev.00/ In AbstractStringBuilder there is a small typo, k:

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

2014-02-26 Thread Paul Sandoz
On Feb 25, 2014, at 9:36 PM, Brian Burkhalter brian.burkhal...@oracle.com wrote: On Feb 25, 2014, at 4:26 AM, Paul Sandoz wrote: Might as well just remove the @Deprecated stuff. I think it is fine under the circumstances to have offsets and getter methods that return the correct

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

2014-02-26 Thread Paul Sandoz
On Feb 25, 2014, at 9:38 PM, Brian Burkhalter brian.burkhal...@oracle.com wrote: On Feb 20, 2014, at 1:42 AM, Paul Sandoz wrote: Not sure the static powerCache field, in the original code, needs to be volatile either: 1137 private static volatile BigInteger[][] powerCache

Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

2014-02-26 Thread Paul Sandoz
Hi, Out of all the methods on Unsafe i think the monitorEnter/monitorExit/tryMonitorEnter are the least used and are very strong candidates for removal. 99% of use-cases are supported by classes in the java.util.concurrent.locks package. Within the JDK itself it is only used in one JDK test

Unsafe: efficiently comparing two byte arrays

2014-02-26 Thread Paul Sandoz
Hi, A common reason why Unsafe is used is to more efficiently compare two unsigned byte arrays, viewing those byte arrays as long arrays. See Guava [1] and a number of apache frameworks for similar code. One solution is to provide such functionality in Arrays for all primitives and probably

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

2014-02-26 Thread Paul Sandoz
On Feb 26, 2014, at 8:35 PM, Brian Burkhalter brian.burkhal...@oracle.com wrote: […] private int firstNonzeroIntNum() { int fn = firstNonzeroIntNumPlusTwo - 2; I made all suggested changes except the third line below. Why do we test for equality with -3? If the primitive int

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

2014-02-26 Thread Paul Sandoz
On Feb 26, 2014, at 8:55 PM, Brian Burkhalter brian.burkhal...@oracle.com wrote: On Feb 26, 2014, at 5:38 AM, Paul Sandoz wrote: Not sure the static powerCache field, in the original code, needs to be volatile either: 1137 private static volatile BigInteger[][] powerCache

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

2014-02-27 Thread Paul Sandoz
On Feb 27, 2014, at 12:51 AM, Brian Burkhalter brian.burkhal...@oracle.com wrote: On Feb 26, 2014, at 1:53 PM, Paul Sandoz wrote: Thanks for the suggestion, Paul. Assuming it is correct, in what way would this be a better approach? (I apologize for being obtuse.) IMHO

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

2014-02-27 Thread Paul Sandoz
On Feb 27, 2014, at 12:32 AM, Brian Burkhalter brian.burkhal...@oracle.com wrote: On Feb 26, 2014, at 1:29 PM, Paul Sandoz wrote: I made all suggested changes except the third line below. Why do we test for equality with -3? If the primitive int default value of zero is used

Re: Unsafe: efficiently comparing two byte arrays

2014-02-27 Thread Paul Sandoz
On Feb 26, 2014, at 6:21 PM, Martin Buchholz marti...@google.com wrote: Every once in a while I see an attempt to introduce a general purpose unsafe array class, but efforts stall due to: Yes, in general this is arrays 2.0 stuff, which is tricky especially since on and off-heap seem to

Re: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

2014-02-27 Thread Paul Sandoz
On Feb 26, 2014, at 7:10 PM, Brian Goetz brian.go...@oracle.com wrote: Seems like a symbolic victory, at least :) I'll take what ever small victory i can with this beast of a class :-) It's less unsafe than some unsafe methods (you can use it to create a DoS but not to violate safety

Re: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

2014-02-27 Thread Paul Sandoz
On Feb 27, 2014, at 12:52 PM, Peter Levart peter.lev...@gmail.com wrote: Ok, then what about the following: static boolean isLocked(final Object monitor, final long millis) throws InterruptedException { return new Thread() { volatile boolean unlocked;

Re: Unsafe: efficiently comparing two byte arrays

2014-02-27 Thread Paul Sandoz
On Feb 27, 2014, at 3:52 PM, Andrew Haley a...@redhat.com wrote: Hi, On 02/26/2014 03:42 PM, Paul Sandoz wrote: A common reason why Unsafe is used is to more efficiently compare two unsigned byte arrays, viewing those byte arrays as long arrays. Why not simply provide

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

2014-02-27 Thread Paul Sandoz
On Feb 27, 2014, at 2:50 PM, Peter Levart peter.lev...@gmail.com wrote: On 02/27/2014 09:22 AM, Paul Sandoz wrote: On Feb 27, 2014, at 12:51 AM, Brian Burkhalter brian.burkhal...@oracle.com wrote: On Feb 26, 2014, at 1:53 PM, Paul Sandoz wrote: Thanks for the suggestion, Paul. Assuming

Re: Unsafe: efficiently comparing two byte arrays

2014-02-27 Thread Paul Sandoz
On Feb 27, 2014, at 4:12 PM, Andrew Haley a...@redhat.com wrote: On 02/27/2014 03:05 PM, Paul Sandoz wrote: On Feb 27, 2014, at 3:52 PM, Andrew Haley a...@redhat.com wrote: Hi, On 02/26/2014 03:42 PM, Paul Sandoz wrote: A common reason why Unsafe is used is to more efficiently

Re: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

2014-02-27 Thread Paul Sandoz
Hi David, On Feb 27, 2014, at 3:24 PM, David M. Lloyd david.ll...@redhat.com wrote: (I'm the guy that wrote JBoss Modules, i.e. apparently the one usage in the wild of these methods). Yes :-) the only one i have found so far. IIUC JBoss Modules only needs to use those methods on Java 1.6,

  1   2   3   4   5   6   7   8   9   10   >