Re: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do

> On Dec 17, 2015, at 6:05 PM, Tao Mao wrote: > > Hi Kim, > > 34 * Suppose the garbage collector determines at a certain point in time > 35 * that an object is > 36 * phantom reachable. At that time it will atomically clear > 37 * all phantom references to that object and all phant

Re: RFR: 8145686: SimpleConsoleLogger and LogRecord should take advantage of StackWalker to skip classes implementing System.Logger

> On Dec 17, 2015, at 11:23 AM, Daniel Fuchs wrote: > > On 12/17/15 7:02 PM, Mandy Chung wrote: >> >>> On Dec 17, 2015, at 8:42 AM, Daniel Fuchs wrote: >>> >>> Hi, >>> >>> Please find below a small enhancement for the method that infers >>> the calling class name and method name in SimpleCo

RFR (JAXP): 8144967: javax.xml.transform.Source and org.xml.sax.InputSource can be empty

Hi, Adding a convenient method isEmpty to javax.xml.transform.Source and org.xml.sax.InputSource. JBS: https://bugs.openjdk.java.net/browse/JDK-8144967 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8144967/webrev/ Thanks, Joe

Re: RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile

On 12/17/2015 08:21 PM, Paul Sandoz wrote: >> On 17 Dec 2015, at 16:54, Aleksey Shipilev >> wrote: >> On 12/17/2015 06:07 PM, Doug Lea wrote: >>> On 12/16/2015 05:53 PM, Aleksey Shipilev wrote: Since the dawn of OpenJDK, AbstractMap.keySet and .value were defined as package-private vola

Re: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do

On Dec 4, 2015, at 1:07 PM, Kim Barrett wrote: > > On Dec 3, 2015, at 6:04 PM, Mandy Chung wrote: >> >>> [Indeed, this whole section isn't strictly necessary; all of it can be >>> inferred from information in other places.] >> >> Agree. This section is no longer necessary and maybe just remov

Re: RFR: 8145686: SimpleConsoleLogger and LogRecord should take advantage of StackWalker to skip classes implementing System.Logger

On 12/17/15 7:02 PM, Mandy Chung wrote: On Dec 17, 2015, at 8:42 AM, Daniel Fuchs wrote: Hi, Please find below a small enhancement for the method that infers the calling class name and method name in SimpleConsoleLogger and LogRecord. The idea is that since these methods now use the new St

Re: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem

This is surely progress, but no one seems to own the problem of fixing all the stat calls in the JDK. Instead of failing at startup, we may get a more obscure failure later at runtime, which not everyone will think is progress. On Thu, Dec 17, 2015 at 5:32 AM, Kumar Srinivasan wrote: > > On 12/16

Re: RFR:8143413:add toEpochSecond methods for efficient access

Hi all, Please see the updated webrev http://cr.openjdk.java.net/~ntv/8143413/webrev.03/ Thanks and Regards, Nadeesh On 12/4/2015 3:56 AM, Stephen Colebourne wrote: In the interests of harmony and getting something in, I'll accept that. I think LocalDate.EPOCH is probably better than LocalD

Re: RFR: 8145686: SimpleConsoleLogger and LogRecord should take advantage of StackWalker to skip classes implementing System.Logger

> On Dec 17, 2015, at 8:42 AM, Daniel Fuchs wrote: > > Hi, > > Please find below a small enhancement for the method that infers > the calling class name and method name in SimpleConsoleLogger > and LogRecord. > > The idea is that since these methods now use the new StackWalker API > they shou

Re: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1

On 12/17/2015 08:18 PM, Paul Sandoz wrote: > >> On 17 Dec 2015, at 17:54, Roger Riggs wrote: >> >> I agree that you should just push it and move on. >> > > +1 Thanks Claes, Sherman, Roger, and Paul! Pushed. Cheers, -Aleksey

Re: RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile

> On 17 Dec 2015, at 16:54, Aleksey Shipilev > wrote: > > On 12/17/2015 06:07 PM, Doug Lea wrote: >> On 12/16/2015 05:53 PM, Aleksey Shipilev wrote: >>> Since the dawn of OpenJDK, AbstractMap.keySet and .value were defined as >>> package-private volatile fields. Their only use is to cache keySe

Re: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1

> On 17 Dec 2015, at 17:54, Roger Riggs wrote: > > I agree that you should just push it and move on. > +1 Paul.

Re: RFR 4823133: RandomAccessFile.length() is not thread-safe

Looks good! On Thu, Dec 17, 2015 at 12:14 AM, vyom wrote: > Hi Martin, > > thanks for review, i undated the > webrev(http://cr.openjdk.java.net/~vtewari/4823133/webrev0.2/ > ) as per your > comment after confirming that the corresponding "

Re: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1

Hi Aleksey, I should have worded it as a suggestion (and provided the words) so as avoided impeding progress. It could have been as general as saying that an @implNote that String is uniquely performance sensitive, that would apply to the whole file, not just a few expressions, and it should p

Re: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1

On 12/17/2015 04:54 PM, Ulf Zibis wrote: > Am 17.12.2015 um 08:54 schrieb Aleksey Shipilev: >> On 12/17/2015 02:34 AM, Ulf wrote: >>> I'm wondering why moving the increment operation to an extra line wound >>> enhance performance. >> Because C1 is very straightforward, and code movement like that i

RFR: 8145686: SimpleConsoleLogger and LogRecord should take advantage of StackWalker to skip classes implementing System.Logger

Hi, Please find below a small enhancement for the method that infers the calling class name and method name in SimpleConsoleLogger and LogRecord. The idea is that since these methods now use the new StackWalker API they should take advantage of that in order to skip classes that implement Syste

Re: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1

Hi Roger, Um, do you really want to spell out "thou shalt run thee benchmarks while changing the String hotpath" in source code comments? I disagree: documenting development processes in the source code is odd. But equally odd is the suggestion that a common development practice would *not* invol

Re: Review Request 8144553: java/lang/StackWalker/StackWalkTest.java and MultiThreadStackWalk.java fail with stack overflows

On 17/12/15 17:07, Mandy Chung wrote: On Dec 17, 2015, at 7:39 AM, Daniel Fuchs wrote: On 17/12/15 16:22, Mandy Chung wrote: On Dec 17, 2015, at 6:02 AM, Daniel Fuchs wrote: Hi Mandy, I believe it would be good to have some test that go over the 1024 limit - as this has been useful to de

Re: Review Request 8144553: java/lang/StackWalker/StackWalkTest.java and MultiThreadStackWalk.java fail with stack overflows

> On Dec 17, 2015, at 7:39 AM, Daniel Fuchs wrote: > > On 17/12/15 16:22, Mandy Chung wrote: >>> On Dec 17, 2015, at 6:02 AM, Daniel Fuchs wrote: >>> > >>> >Hi Mandy, >>> > >>> >I believe it would be good to have some test that go over >>> >the 1024 limit - as this has been useful to detect bug

Re: RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile

On 12/17/2015 06:07 PM, Doug Lea wrote: > On 12/16/2015 05:53 PM, Aleksey Shipilev wrote: >> Since the dawn of OpenJDK, AbstractMap.keySet and .value were defined as >> package-private volatile fields. Their only use is to cache keySet and >> valueSet implementations from java.util collections. >

Re: Review Request 8144553: java/lang/StackWalker/StackWalkTest.java and MultiThreadStackWalk.java fail with stack overflows

On 17/12/15 16:22, Mandy Chung wrote: On Dec 17, 2015, at 6:02 AM, Daniel Fuchs wrote: > >Hi Mandy, > >I believe it would be good to have some test that go over >the 1024 limit - as this has been useful to detect bugs >when we were actively prototyping the API. > >So maybe we should first try t

Re: RFR [9] 8145589: Test6277246.java fails to compile after JDK-8144479

+1 On 12/17/2015 10:15 AM, Chris Hegarty wrote: For ease of review, I moved the complete changes into a webrev. http://cr.openjdk.java.net/~chegar/8145589/webrev/ -Chris. On 17 Dec 2015, at 15:08, Chris Hegarty wrote: On 17 Dec 2015, at 14:54, Roger Riggs wrote: Hi Chris, Looks fine

Re: Review Request 8144553: java/lang/StackWalker/StackWalkTest.java and MultiThreadStackWalk.java fail with stack overflows

> On Dec 17, 2015, at 6:02 AM, Daniel Fuchs wrote: > > Hi Mandy, > > I believe it would be good to have some test that go over > the 1024 limit - as this has been useful to detect bugs > when we were actively prototyping the API. > > So maybe we should first try to reduce from 2000 to e.g. 10

Re: RFR [9] 8145589: Test6277246.java fails to compile after JDK-8144479

For ease of review, I moved the complete changes into a webrev. http://cr.openjdk.java.net/~chegar/8145589/webrev/ -Chris. On 17 Dec 2015, at 15:08, Chris Hegarty wrote: > On 17 Dec 2015, at 14:54, Roger Riggs wrote: > >> Hi Chris, >> >> Looks fine. > > Thanks Roger. Just a little additi

Re: RFR [9] 8145589: Test6277246.java fails to compile after JDK-8144479

On 17 Dec 2015, at 14:54, Roger Riggs wrote: > Hi Chris, > > Looks fine. Thanks Roger. Just a little addition to this review. While not strictly necessary, I’d like to clean up another, string, reference use in a reflective call. ( It is not causing a failure as the security manager will restr

Re: RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile

On 12/16/2015 05:53 PM, Aleksey Shipilev wrote: Hi, Since the dawn of OpenJDK, AbstractMap.keySet and .value were defined as package-private volatile fields. Their only use is to cache keySet and valueSet implementations from java.util collections. I think these were declared volatile to be mo

Re: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1

Hi Alexsey, The 'expected to run benchmarks' might the operative comment in the code. 'Common' knowledge sometimes isn't so common. Roger On 12/17/2015 2:54 AM, Aleksey Shipilev wrote: On 12/17/2015 02:34 AM, Ulf wrote: I'm wondering why moving the increment operation to an extra line wound

Re: RFR: JDK-8145596 Enable debug symbols for all libraries

Looks good to me. Note that this patch will conflict with the quick fix I did in jdk9/hs, so you will need to either wait for my patch, push in a forest that has my patch, or make sure the integrator can handle it correctly. /Erik On 2015-12-17 14:43, Magnus Ihse Bursie wrote: For historical

Re: RFR [9] 8145589: Test6277246.java fails to compile after JDK-8144479

Hi Chris, Looks fine. Roger On 12/17/2015 9:46 AM, Chris Hegarty wrote: The removal of BASE64Encoder, and a related types, in 8144479 [1] has triggered the failure of java/beans/Introspector/Test6277246.java. Another internal type should be used instead of sun.misc.BASE64Encoder. The sun.secu

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

fyi, I filed a separate bug[1] to add the reachabilityFence calls when they reach jdk-dev. Roger [1] https://bugs.openjdk.java.net/browse/JDK-8145459 On 12/17/2015 7:53 AM, Paul Sandoz wrote: On 17 Dec 2015, at 13:07, Peter Levart wrote: I see no other issues left besides the reachability

RFR [9] 8145589: Test6277246.java fails to compile after JDK-8144479

The removal of BASE64Encoder, and a related types, in 8144479 [1] has triggered the failure of java/beans/Introspector/Test6277246.java. Another internal type should be used instead of sun.misc.BASE64Encoder. The sun.security.x509 package seems stable, and is being used in other areas, like langtoo

Re: Review Request 8144553: java/lang/StackWalker/StackWalkTest.java and MultiThreadStackWalk.java fail with stack overflows

Hi Mandy, I believe it would be good to have some test that go over the 1024 limit - as this has been useful to detect bugs when we were actively prototyping the API. So maybe we should first try to reduce from 2000 to e.g. 1028? best regards, -- daniel On 16/12/15 21:30, Mandy Chung wrote:

Re: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1

Am 17.12.2015 um 08:54 schrieb Aleksey Shipilev: On 12/17/2015 02:34 AM, Ulf wrote: I'm wondering why moving the increment operation to an extra line wound enhance performance. Because C1 is very straightforward, and code movement like that is a poor man's instruction scheduling, that pads out

Re: RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile

Hi Peter, On 12/17/2015 03:19 PM, Peter Levart wrote: > Wouldn't that change make a possible outcome of keySet() returning null > in case it was invoked concurrently? Wouldn't you have to use a local > variable to prevent that? Ah yes! Silly me. I remember looking at most usages and seeing that r

Re: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

Hi Jason, Thank you for your comment. I've fixed it in new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.03/ Thanks, Yasumasa On 2015/12/17 0:33, Jason Mehrens wrote: The null check of 'entry' at line 351 of ZipFile.getInputStream is in conflict with line 350 and 348.

RFR: JDK-8145596 Enable debug symbols for all libraries

For historical reasons, the FDS (Full Debug Symbols) project only enabled debug symbols for a few select libraries, since this was difficult to achieve in the old build. Also, the FDS project never enabled debug symbols for macosx on the JDK libraries. With the new build system, debug symbols

Re: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem

On 12/16/2015 11:01 AM, Martin Buchholz wrote: On Tue, Dec 15, 2015 at 2:12 PM, Bernd Eckenfels wrote: Hello, I always like it when access() is used instead of stat() magic. I noticed that the new ProgramExists in java_md_common.c does not anymore reject directories (which are typically exec

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

> On 17 Dec 2015, at 13:07, Peter Levart wrote: > > I see no other issues left besides the reachability races that I talked about > in previous messages. Do you know if Reference.reachabilityFence is being > pushed before this API? > It’s already pushed to hs-comp. I dunno when it will wind

Re: RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile

Hi Aleksey, Wouldn't that change make a possible outcome of keySet() returning null in case it was invoked concurrently? Wouldn't you have to use a local variable to prevent that? Regards, Peter On 12/16/2015 11:53 PM, Aleksey Shipilev wrote: Hi, Since the dawn of OpenJDK, AbstractMap.keyS

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Roger, On 12/16/2015 08:47 PM, Roger Riggs wrote: Hi Peter, It was a bit more involved than I expected, mostly in the tests to make this change. Is this what you expected? (just the deltas, I'll merge the patches before pushing). http://cr.openjdk.java.net/~rriggs/webrev-cleaner-81386

Re: Review request for JDK-8145545 : Typos in Javadoc of XmlAdapter

Looks fine. Regards, Sean. On 17/12/2015 08:55, Abhijit Roy wrote: Hi all, Please review a fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8145545 Bug - Typos in Javadoc of XmlAdapter Webrev - http://cr.openjdk.java.net/~ntv/ababroy/8145545/webrev.00/ I have just rectified and

Review request for JDK-8145545 : Typos in Javadoc of XmlAdapter

Hi all,  Please review a fix for Bug  - https://bugs.openjdk.java.net/browse/JDK-8145545  Bug - Typos in Javadoc of XmlAdapter Webrev - http://cr.openjdk.java.net/~ntv/ababroy/8145545/webrev.00/  I have just rectified and modified those error. And moving forward it for review.     Regards,

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

Hi Coleen You have previously reviewed this enhancement and made a few comments I have resolved them, so could you look at the webrevs again, please? I have added tests, removed cp tags that are not in JVM spec (100 - 105) and made some other changes. JDK: http://cr.openjdk.java.net/~kshefov/

Re: RFR 4823133: RandomAccessFile.length() is not thread-safe

Hi Martin, thanks for review, i undated the webrev(http://cr.openjdk.java.net/~vtewari/4823133/webrev0.2/ ) as per your comment after confirming that the corresponding "fd" if opened with "open64". Thanks, Vyom On Thursday 17 Decem