ThreadLocal with null initial values - avoid create map and entry?

Hello, while debugging and optimizing some application ThreadLocal code I noticed, that if I not use the initialValue() method for filling a start value, I could often use the null value to shortcut processing. I.e. I would add a object with some state to clean up, but if there is no object, I kn

Re: RFR 9: 8064932: test java/lang/ProcessBuilder/Basic.java: waitFor didn't take long enough

Hi Martin, On 18/11/2014 2:49 PM, Martin Buchholz wrote: Hi David, I'm still hoping to persuade you (and others) to fix the long-standing return-early bug in Object.wait. Are you referring to the low level mechanics or specifically to the nanosecond version below? As new support for my po

Re: RFR 9: 8064932: test java/lang/ProcessBuilder/Basic.java: waitFor didn't take long enough

On 18/11/2014 2:43 PM, Martin Buchholz wrote: Proposed sibling change http://cr.openjdk.java.net/~martin/webrevs/openjdk9/UNIXProcess.waitFor/ - don't unconditionally call nanoTime when the wait ends - use the millis/nanos form of Object.wait in case sub-millisecond waits are ever supported. I

Re: RFR 9: 8064932: test java/lang/ProcessBuilder/Basic.java: waitFor didn't take long enough

Hi David, I'm still hoping to persuade you (and others) to fix the long-standing return-early bug in Object.wait. As new support for my position I offer the "at least" in JLS https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.2.1 """ If this is a timed wait, an internal actio

Re: RFR 9: 8064932: test java/lang/ProcessBuilder/Basic.java: waitFor didn't take long enough

Proposed sibling change http://cr.openjdk.java.net/~martin/webrevs/openjdk9/UNIXProcess.waitFor/ - don't unconditionally call nanoTime when the wait ends - use the millis/nanos form of Object.wait in case sub-millisecond waits are ever supported. On Mon, Nov 17, 2014 at 6:28 PM, Martin Buchholz w

Re: RFR 9: 8064932: test java/lang/ProcessBuilder/Basic.java: waitFor didn't take long enough

I was staring at that old process code I wrote many years ago, and I think it can be improved. I'll post a patch later. On Mon, Nov 17, 2014 at 2:02 PM, roger riggs wrote: > Hi, > > The technique used in the Linux version of Process.waitFor() is applied to > the Windows version. The duration of

Re: RFR 9: 8064932: test java/lang/ProcessBuilder/Basic.java: waitFor didn't take long enough

Hi Roger, On 18/11/2014 8:02 AM, roger riggs wrote: Hi, The technique used in the Linux version of Process.waitFor() is applied to the Windows version. The duration of the native wait is measured using nanoTime and the wait is repeated as necessary. For most uses, some jitter is expected due

Re: [8u40] Review request 8064667: Provide support to help identify use of endorsed standards and extension mechanism

Updated webrev: http://cr.openjdk.java.net/~mchung/jdk8u/webrevs/8064667/webrev.01/ This addresses Calvin's comment. It now keeps a list of the jar files shipped with jre/lib/ext and determine if jre/lib/ext has any other non-JDK jar files installed. Mandy On 11/17/2014 8:57 AM, Mandy Chung

Several issues with java.net.URLConnection

Hi everyone, I've been working with the URLConnection class for some time now and have noticed several interesting things. 1. Unsafe publication of java.net.URLConnection.factory static field (it looks very similar to [1]) 2. Benign race condition in java.net.URLConnection.getContentHandler on

Re: RFR (S): 8065070: (fmt) Avoid creating substrings when building FormatSpecifier

On 2014-11-17 18:31, Martin Buchholz wrote: I'll add my reviewer-bit (let's give more good people reviewer bits!). Looks good! Thanks for reviewing! /Claes

Re: RFR: 8064846: Lazy-init thread safety problems in core reflection

On Mon, Nov 17, 2014 at 1:15 PM, Joel Borggrén-Franck wrote: > IIRC The jdk contains 4 subtypes of Type. I think Peter is right here, but on > the other hand aren't uncontended volatile reads kind of cheap? Unless > someone comes back with reports of measurable slowdown I think safe > publicat

Re: RFR 9: 8064932: test java/lang/ProcessBuilder/Basic.java: waitFor didn't take long enough

Hi, The technique used in the Linux version of Process.waitFor() is applied to the Windows version. The duration of the native wait is measured using nanoTime and the wait is repeated as necessary. For most uses, some jitter is expected due to workload, clock resolution, etc. Webrev: http:

Re: RFR: 8062773: Clarifications for Class specification

Submitted. On Fri, Nov 14, 2014 at 12:22 PM, Martin Buchholz wrote: > Companion change to getFields has been submitted. I plan on > submitting this one soon if I don't hear any objections. > > On Thu, Nov 6, 2014 at 11:05 AM, Martin Buchholz wrote: >> I moved the change to getFields to another

Re: RFR: 8064846: Lazy-init thread safety problems in core reflection

Hi, > On 14 Nov 2014, at 22:48, Martin Buchholz wrote: > > On Fri, Nov 14, 2014 at 9:32 AM, Peter Levart wrote: >> Hi Martin, >> >> I dont know if you saw https://bugs.openjdk.java.net/browse/JDK-8064517 (a >> followup to your fix for final fields). It would be best to merge those >> fixes, wh

Re: RFR 9: 8064932: test java/lang/ProcessBuilder/Basic.java: waitFor didn't take long enough

Returning early is EVIL. ("""What part of 'wait for NNN nanoseconds' did you not understand??""") Unfortunately, Object.wait may do so. And perhaps also waitForMultipleObjects. HIgher level libraries need to be paranoid and compensate. On Mon, Nov 17, 2014 at 11:27 AM, roger riggs wrote: > Hi, >

Re: RFR 9: 8064932: test java/lang/ProcessBuilder/Basic.java: waitFor didn't take long enough

Hi, I need to go back and identify the platform of the failure; it is failing on Windows so the correct code is in ProcessImpl_md.c in waitForTimeoutInterruptibly in which the timeout is in milliseconds. If waitForMultipleObjects can return 'early' then the same kind of loop used on Linux for

Re: RFR (XS) 8065096: java.net.Authenticator.theAuthenticator should be properly synchronized

Hey, all of you guys... this must be the fastest turnaround ever! Thanks a lot, very much appreciated (even if it wasn't that crucial, only something I accidentally spotted in the code). Dawid On Mon, Nov 17, 2014 at 5:26 PM, Claes Redestad wrote: > On 11/17/2014 01:31 PM, Aleksey Shipilev wrote

Re: RFR (S): 8065070: (fmt) Avoid creating substrings when building FormatSpecifier

I'll add my reviewer-bit (let's give more good people reviewer bits!). Looks good! (but also demonstrates deep existing problems with substring change) Not a defect with this change, but it looks to me like those assert(false) will trigger if e.g. a number is specified that is greater than Intege

Re: [9] Review Request: 8059753 Fix for java/security/Security/ClassLoaderDeadlock/Deadlock2.sh fails with exit code 1

Hi Pooja, This test will need to be examined and updated (see JDK-8062758 [1]). The deadlock bug this test verifies is not specific the extension class loader. Although your patch is orthogonal to JDK-8062758, I wonder if you or Rajan can help look into updating this bug to verify JDK-64408

Re: RFR (XS) 8065096: java.net.Authenticator.theAuthenticator should be properly synchronized

On 11/17/2014 01:31 PM, Aleksey Shipilev wrote: Thanks for reviews! Please push: http://cr.openjdk.java.net/~shade/8065096/8065096.changeset -Aleksey. I'll be happy to sponsor and push this for you. /Claes

Re: AnnotationInvocationHandler - null check for hashCode / equals / toString computation?

Hello again, I looked a little closer at the implementation of the AnnotationInvocationHandler and I want to extend my question beyond the equals method: When I define an annotation @Foo{ String value() } and instantiate two such annotations as @Foo("bar") class First {} and @Foo("bar") class

Re: AnnotationInvocationHandler - null check for hashCode / equals / toString computation?

Thanks for clearing this up Aleksey, I should have posted an example right away so here is some code that reproduces the NullPointerException where I would either expect: (a) an IncompleteAnnotationException or (b) a return value of false. I guess returning false makes more sense as one expects to

Re: RFR (XS) 8065096: java.net.Authenticator.theAuthenticator should be properly synchronized

Thanks for reviews! Please push: http://cr.openjdk.java.net/~shade/8065096/8065096.changeset -Aleksey. On 11/17/2014 03:15 PM, Lance @ Oracle wrote: > Looks fine aleksey > > > Lance Andersen| > Principal Member of Technical Staff | +1.7

Re: RFR (S): 8065070: (fmt) Avoid creating substrings when building FormatSpecifier

On 11/17/2014 03:23 PM, Claes Redestad wrote: > > On 2014-11-17 12:54, Aleksey Shipilev wrote: >>> Perhaps rewriting to something like this would make the code >>> cleaner: >>> >>>index(s, m.start(1), m.end(1)); >>>flags(s, m.start(2), m.end(2)); >>>

Re: RFR (S): 8065070: (fmt) Avoid creating substrings when building FormatSpecifier

On 2014-11-17 12:54, Aleksey Shipilev wrote: Perhaps rewriting to something like this would make the code cleaner: index(s, m.start(1), m.end(1)); flags(s, m.start(2), m.end(2)); width(s, m.start(3), m.end(3)); precision(s, m.start(4),

Re: RFR (XS) 8065096: java.net.Authenticator.theAuthenticator should be properly synchronized

Looks fine aleksey Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPad > On Nov 17, 2014, at 5:35 AM, Aleksey Shipilev > wrote: > > Hi, > > Please review and commit thi

Re: RFR (XS) 8065096: java.net.Authenticator.theAuthenticator should be properly synchronized

Thanks for submitting the review Aleksey. Reviewed. -Chris. On 17 Nov 2014, at 10:35, Aleksey Shipilev wrote: > Hi, > > Please review and commit this trivial change: > http://cr.openjdk.java.net/~shade/8065096/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8065096 > > "volatile" should

Re: RFR (S): 8065070: (fmt) Avoid creating substrings when building FormatSpecifier

On 11/17/2014 02:49 PM, Claes Redestad wrote: > On 2014-11-17 11:45, Aleksey Shipilev wrote: >> On 11/17/2014 02:09 AM, Claes Redestad wrote: >>> http://cr.openjdk.java.net/~redestad/8065070/webrev.00 >>> https://bugs.openjdk.java.net/browse/JDK-8065070 >> (Not a Reviewer) The change looks very san

Re: RFR (S): 8065070: (fmt) Avoid creating substrings when building FormatSpecifier

On 2014-11-17 11:45, Aleksey Shipilev wrote: On 11/17/2014 02:09 AM, Claes Redestad wrote: http://cr.openjdk.java.net/~redestad/8065070/webrev.00 https://bugs.openjdk.java.net/browse/JDK-8065070 (Not a Reviewer) The change looks very sane given the capture ranges are already available in Matche

Re: Inconsistent access/ synchronization on Authenticator.theAuthenticator

Thanks Aleksey. Can't file Jira issues myself, unfortunately; holding my word to Rory's promise that there will be a public Jira subscription access at some point -- it'd help a lot for those who wish to track changes on issues and currently have to do it manually. Dawid On Mon, Nov 17, 2014 at 1

Re: RFR: 8064846: Lazy-init thread safety problems in core reflection

On 11/15/2014 12:38 AM, Martin Buchholz wrote: > I've implemented your suggestions and regenerated the webrev. Looks good, thanks! -Aleksey.

Re: RFR (S): 8065070: (fmt) Avoid creating substrings when building FormatSpecifier

On 11/17/2014 02:09 AM, Claes Redestad wrote: > http://cr.openjdk.java.net/~redestad/8065070/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8065070 (Not a Reviewer) The change looks very sane given the capture ranges are already available in Matcher. I wonder if you want to cache m.start() a

RFR (XS) 8065096: java.net.Authenticator.theAuthenticator should be properly synchronized

Hi, Please review and commit this trivial change: http://cr.openjdk.java.net/~shade/8065096/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8065096 "volatile" should nominally fix the the data race on theAuthenticator field. Thanks, -Aleksey.

Re: Inconsistent access/ synchronization on Authenticator.theAuthenticator

On 11/17/2014 12:56 PM, Dawid Weiss wrote: > This is very minor, but java.net.Authenticator has the following > static field for the default authenticator: > > private static Authenticator theAuthenticator; > > This field is set from a synchronized method setDefault(..), but > accessed withou

Inconsistent access/ synchronization on Authenticator.theAuthenticator

This is very minor, but java.net.Authenticator has the following static field for the default authenticator: private static Authenticator theAuthenticator; This field is set from a synchronized method setDefault(..), but accessed without proper sync from all other request* methods: Authentic

Re: AnnotationInvocationHandler - null check for hashCode / equals / toString computation?

On 11/17/2014 12:52 PM, Aleksey Shipilev wrote: > Like Rafael, I wonder if we can/should throw the > IncompleteAnnotationException when accessing the annotation member > implicitly with equals(), not with the named accessor. This should be "*as well as explicitly* with the named accessor". -Aleks

Re: AnnotationInvocationHandler - null check for hashCode / equals / toString computation?

Hi Joe, I am missing something. Of course, JLS requires the reference types members of annotations to be non-null. But IncompleteAnnotationEx is here to cover the case when the annotation is mis-constructed. Therefore, I think the original Rafael's question is still unanswered. I can see how the

Re: RFR: 8064914: tzdb.dat compilation failure when using tzdata2014j

Looks fine. Thanks for handling. regards, Sean. On 17/11/2014 00:11, Aleksej Efimov wrote: Hello, During the latest tzdata (2014j) integration the tzdb.dat build failure was observed - details can be found in JBS [1]. The proposed [2] fix resolves time zones double link problem and JDK compi