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

> On May 15, 2015, at 12:09 PM, Brent Christian > wrote: > > Updated webrev: > > http://cr.openjdk.java.net/~bchristi/8029891/webrev.1/ > > I have restored synchronization to modification methods, and to my > interpretation of "bulk read" operations: > >* forEach >* replaceAll >

RFR 8080640: Reduce copying when reading JAR/ZIP entries

Hi, Wanted to get reviews and feedback on this performance improvement for reading from JAR/ZIP files during classloading by reducing unnecessary copying and reading the entry in one go instead of in small portions. This shows a significant improvement when reading a single entry and for a la

Re: Review Request for 8074431: Remove native2ascii tool

On 05/18/2015 03:45 PM, Mandy Chung wrote: This patch removes native2ascii command-line tool from JDK 9 as proposed in March [1]. Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074431/webrev.00/ Jon - A langtools test is updated to use a new Native2Ascii.java helper class instea

Review Request for 8074431: Remove native2ascii tool

This patch removes native2ascii command-line tool from JDK 9 as proposed in March [1]. Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074431/webrev.00/ Jon - A langtools test is updated to use a new Native2Ascii.java helper class instead. Existing code that calls sun.tools.nativ

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

On 5/18/15 3:20 AM, Paul Sandoz wrote: I would like to suggest some tweaks to the specification to get across this method is transitioning control of traversal from enumeration to iterator. How about: Returns an iterator that traverses the remaining elements covered by this enumeration

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

Hi, Daniel You're right, thanks. The situation is the same for elements(). I've updated these in my local repo. I checked through the methods that return a Set/Enumeration/etc, and I believe there's also an issue with entrySet(). The returned Set should be backed by the map, and support r

Re: RFR 9: 8077350 Process API Updates Implementation Review

Hi Peter, On 5/15/2015 6:35 AM, Peter Levart wrote: 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 Stre

Re: RFR 9: 8077350 Process API Updates Implementation Review

On May 18, 2015, at 10:49 PM, Roger Riggs wrote: > Hi Paul, > > Thanks for the comments. > > On 5/18/2015 7:58 AM, Paul Sandoz wrote: >> Ho Roger, >> >> I mostly focused on the specification. >> >> Paul. >> >> >> Process >> -- >> >> 35 * {@code Process} provides control of native proces

Re: RFR 9: 8077350 Process API Updates Implementation Review

Hi Paul, Thanks for the comments. On 5/18/2015 7:58 AM, Paul Sandoz wrote: Ho Roger, I mostly focused on the specification. Paul. Process -- 35 * {@code Process} provides control of native processes started by 36 * ProcessBuilder.start and Runtime.exec. Link to those methods? Links

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

On Fri, May 15, 2015 at 5:59 PM, Ivan Gerasimov wrote: > > > On 16.05.2015 2:18, Martin Buchholz wrote: > > I wouldn't bother defining the constant. > > > I only need it in the regression test, to check whether it was > sufficient. > The problem you're trying to solve is (a small amount of) sta

Re: RFR(XS) : 8055269 : java/lang/invoke/MethodHandles/CatchExceptionTest.java fails intermittently

Ok, now I see long.class in the list :-) Does the test checks 255 limit on slots or logical arguments? It should check slot size, but I don't see logic for computing slot consumption for generated signatures. Best regards, Vladimir Ivanov On 5/18/15 8:58 PM, Vladimir Ivanov wrote: Igor, Lo

Re: RFR(XS) : 8055269 : java/lang/invoke/MethodHandles/CatchExceptionTest.java fails intermittently

Igor, Looks good. You don't need to bother computing slot size for a signature since you use only 1-slot types, do you? test/java/lang/invoke/MethodHandles/CatchExceptionTest.java: Class classes[] = { Object.class, long.class, int.class,

RFR(XS) : 8055269 : java/lang/invoke/MethodHandles/CatchExceptionTest.java fails intermittently

http://cr.openjdk.java.net/~iignatyev/8055269/webrev.00/ 23 lines changed: 8 ins; 9 del; 6 mod Hi all, please review the tiny fix for CatchExceptionTest test. problem: the tests generates a target w/ 255 parameters, so a corresponding handler should have 256 parameters. that violates restrict

Re: Naming of thread pools (Executors)

> On May 17, 2015, at 9:32 PM, Aleksey Shipilev > wrote: > > On 05/17/2015 10:55 AM, Peter Hansson wrote: >> Hi, >> >> I would like create a patch for >> https://bugs.openjdk.java.net/browse/JDK-8016248. >> MOTIVATION: Today thread pools created by the Executors method are always >> prefixe

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

Hi Alexander, seems ok as well… On May 18, 2015, at 12:02 PM, alexander stepanov wrote: > Hello, Lance, Roger, > > Thanks! > > P.S. sorry - one minor change after the review - a list was added in > ExtensionDependency.java: > http://cr.openjdk.java.net/~avstepan/8080422/webrev.02/src/java.

Re: PriorityQueue

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 and a Comparator (2 arguments)? On Thu, May 14, 2015 at 2:08

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

Hello, Lance, Roger, Thanks! P.S. sorry - one minor change after the review - a list was added in ExtensionDependency.java: http://cr.openjdk.java.net/~avstepan/8080422/webrev.02/src/java.base/share/classes/sun/misc/ExtensionDependency.java.udiff.html (please update the page). Regards, Alexan

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

Hi Alexander, Thanks, Looks good to go to me. Roger On 5/18/2015 11:36 AM, alexander stepanov wrote: Hello Roger, Fixed; please see http://cr.openjdk.java.net/~avstepan/8080422/webrev.02/index.html Regards, Alexander On 18.05.2015 17:43, Roger Riggs wrote: Hi Alexander, Thanks for these

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

The revised changes seem OK in addition to the previous webrev Best Lance On May 18, 2015, at 11:36 AM, alexander stepanov wrote: > Hello Roger, > > Fixed; please see > http://cr.openjdk.java.net/~avstepan/8080422/webrev.02/index.html > > Regards, > Alexander > > On 18.05.2015 17:43, Roger

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

Hello Roger, Fixed; please see http://cr.openjdk.java.net/~avstepan/8080422/webrev.02/index.html Regards, Alexander On 18.05.2015 17:43, Roger Riggs wrote: Hi Alexander, Thanks for these needed cleanups; a few corrections below. 1) src/java.base/share/classes/jdk/internal/util/xml/impl/Pa

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

Thanks Chris for your review! This looks much better. Trivially I’d calculate the initial size like: 510 / 0.75 + 1.0f ( plus 1 ) I'll all +1 for extra accuracy. … but your regression test should prove that the plus one is not needed. Maybe a comment that the 0.75 is the default

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

Hi Alexander, Thanks for these needed cleanups; a few corrections below. 1) src/java.base/share/classes/jdk/internal/util/xml/impl/Parser.java: "The grammar *which *this method can read is" can remove the 'which' 2) src/java.base/share/classes/sun/misc/CharacterEncoder.java: 107 The {@c

Re: JEP 254: Compact Strings

> > From a purely performance perspective, the most expensive CPU operations > are memory access these days. Very true ... for random accesses. Anything that halves memory reads will likely produce better performance. This part is a bit unclear for the proposed changes. While it's true that s

RE: JEP 254: Compact Strings

For what it's worth, we would welcome this change. We took a large memory hit and a small performance hit when we upgraded from 1.6 to 1.7 in some of our memory-bound applications. >From a purely performance perspective, the most expensive CPU operations are >memory access these days. Anything

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

Please see the updated webrev http://cr.openjdk.java.net/~avstepan/8080422/webrev.01/ - some misprints were fixed as well (not 100% sure if "comparision" should be replaced with "comparison", but the latter looks more suitable). Thanks, Alexander On 15.05.2015 20:16, alexander stepanov wrote:

Re: RFR 8072853: SimpleScriptContext used by NashornScriptEngine doesn't completely complies to the spec regarding exception throwing

On May 18, 2015, at 2:59 PM, A. Sundararajan wrote: > Thanks for the review. Updated test as per your suggestion. Uploaded fresh > review @ http://cr.openjdk.java.net/~sundar/8072853/webrev.01/ > +1 Paul.

Re: RFR 8072853: SimpleScriptContext used by NashornScriptEngine doesn't completely complies to the spec regarding exception throwing

Also +1 > On 18 May 2015, at 14:59, A. Sundararajan > wrote: > > Thanks for the review. Updated test as per your suggestion. Uploaded fresh > review @ http://cr.openjdk.java.net/~sundar/8072853/webrev.01/ > > Thanks > -Sundar > > Paul Sandoz wrote: >> On May 18, 2015, at 12:44 PM, A. Sundar

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

Thanks, John. What do you think about the following version: http://cr.openjdk.java.net/~vlivanov/8079205/webrev.04 Best regards, Vladimir Ivanov On 5/15/15 8:06 PM, John Rose wrote: I know injected fields are somewhat hacky, but there are a couple of conditions here which would motivate th

RFR(XS): JDK-8077866: [TESTBUG] Some of java.lang tests cannot be run on compact profiles 1, 2

Hi All, Please review the very small change in TEST.groups file. Webrev link: http://cr.openjdk.java.net/~skovalev/dkononen/8077866/webrev.00/ Bug id: JDK-8077866 Testing: automated Description: The following tests cannot be run on compact pr

Re: RFR 8072853: SimpleScriptContext used by NashornScriptEngine doesn't completely complies to the spec regarding exception throwing

Thanks for the review. Updated test as per your suggestion. Uploaded fresh review @ http://cr.openjdk.java.net/~sundar/8072853/webrev.01/ Thanks -Sundar Paul Sandoz wrote: On May 18, 2015, at 12:44 PM, A. Sundararajan wrote: Please review http://cr.openjdk.java.net/~sundar/8072853/webr

Re: RFR 8072853: SimpleScriptContext used by NashornScriptEngine doesn't completely complies to the spec regarding exception throwing

+1 /M > On 18 May 2015, at 12:44, A. Sundararajan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8072853/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8072853 > > Thanks, > -Sundar

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

Everyone, Please review updated version of the fix: http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.07/ Most important part of the fix provided by Peter Levart, so all credentials belongs to him. -Dmitry On 2015-05-16 15:48, Peter Levart wrote: > > > On 05/16/2015 02:38 PM, Peter L

Re: RFR 8072853: SimpleScriptContext used by NashornScriptEngine doesn't completely complies to the spec regarding exception throwing

On May 18, 2015, at 12:44 PM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8072853/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8072853 > Changes to SimpleScriptContext look good. Test-wise you could reduce the duplication with a method accepting C

Re: RFR 9: 8077350 Process API Updates Implementation Review

Ho Roger, I mostly focused on the specification. Paul. Process -- 35 * {@code Process} provides control of native processes started by 36 * ProcessBuilder.start and Runtime.exec. Link to those methods? 92 /** 93 * Default constructor for Process. 94 */ 95 publi

RFR 8072853: SimpleScriptContext used by NashornScriptEngine doesn't completely complies to the spec regarding exception throwing

Please review http://cr.openjdk.java.net/~sundar/8072853/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8072853 Thanks, -Sundar

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

Hi Stuart, I would like to suggest some tweaks to the specification to get across this method is transitioning control of traversal from enumeration to iterator. How about: Returns an iterator that traverses the remaining elements covered by this enumeration. Traversal is undefined if thi

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

On 05/18/2015 10:56 AM, Daniel Fuchs wrote: Hi Stuart, That's an RFE I have often wished for :-) I've been wondering whether a static method in the class java.util.Collections would be better, since there already are some conversion methods there - like: public static Enumeration emptyEnumera

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

Hi Stuart, That's an RFE I have often wished for :-) I've been wondering whether a static method in the class java.util.Collections would be better, since there already are some conversion methods there - like: public static Enumeration emptyEnumeration(); public static Enumeration enumeratio

Re: Naming of thread pools (Executors)

On 05/17/2015 10:55 AM, Peter Hansson wrote: > Hi, > > I would like create a patch for > https://bugs.openjdk.java.net/browse/JDK-8016248. > MOTIVATION: Today thread pools created by the Executors method are always > prefixed with "pool". The developer can work around this by providing his own