Re: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault

The fix still looks good to me. Thanks, Serguei On 12/1/14 6:39 PM, Chris Plummer wrote: Sorry about the long delay in getting back to this. I ran into two separate JPRT issues that were preventing me from testing these changes, plus I was on vacation last week. Here's an updated webrev. I'm

Re: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support eviction

Reviewed. I sympathize with Paul's "gnarly" comment. Nice bit of stream-ology (rheology) in the test code. Regarding: > On Dec 2, 2014, at 8:20 AM, Vladimir Ivanov > wrote: >> >> In src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java >> >> 366 lambdaForm.

Re: RFR 8060068 : Remove the static initializer block from DriverManager

On 12/2/2014 1:47 PM, Lance Andersen wrote: The revised webrev is here http://cr.openjdk.java.net/~lancea/8060068/webrev.03/ Looks good. Nit: line 443 and a few places in the getConnection need a space in "for(", "if(" Note, I

Re: Review request for JDK-8051536: Convert JAXP function tests: javax.xml.parsers to jtreg(testng) tests

I agree with Lance's suggestion on utilizing the @BeforeMethod methods to instantiate factories, or DocumentBuilder where there's no change in state on the DocumentBuilderFactory (that is, no set** in any of the tests, such as DocumentBuilderImpl01), or using DataProvider. However, if you do m

Re: More memory-efficient internal representation for Strings: call for more data

On 12/02/2014 04:42 PM, Douglas Surber wrote: The most common operation on most Strings in query results is to do nothing. Just construct the String, hold onto it while the rest of the transaction completes, then drop it on the floor. Probably the next most common is to encode the chars to wri

Re: More memory-efficient internal representation for Strings: call for more data

The most common operation on most Strings in query results is to do nothing. Just construct the String, hold onto it while the rest of the transaction completes, then drop it on the floor. Probably the next most common is to encode the chars to write them to an OutputStream or send them back to

Re: More memory-efficient internal representation for Strings: call for more data

On 12/02/2014 03:24 PM, Douglas Surber wrote: String construction is a big performance issue for JDBC drivers. Most queries return some number of Strings. The overwhelming majority of those Strings will be short lived. The cost of constructing these Strings from network bytes is a large fracti

Re: More memory-efficient internal representation for Strings: call for more data

Hi Douglas, On 12/03/2014 02:24 AM, Douglas Surber wrote: > String construction is a big performance issue for JDBC drivers. Most > queries return some number of Strings. The overwhelming majority of > those Strings will be short lived. The cost of constructing these > Strings from network bytes i

Java 8 FilterOutputStream.close() bug

Hi, I have encountered a bug in FilterOutputStream under Java 8. The bug is that calling close() on the same stream twice can now result in an exception, whereas under Java 7 it did not. The reason is that FilterOutputStream.close() calls flush() before calling close() on the underlying strea

Re: RFR 8060068 : Remove the static initializer block from DriverManager

Hello Mandy and Lance, (sorry, not a full quote for more focused answers, inline) Am Tue, 02 Dec 2014 14:10:06 -0800 schrieb Mandy Chung : > Would you be able to try this patch and see if the deadlocks are > reproducible? Lance has been trying to get customers to verify this > patch as this c

Re: More memory-efficient internal representation for Strings: call for more data

String construction is a big performance issue for JDBC drivers. Most queries return some number of Strings. The overwhelming majority of those Strings will be short lived. The cost of constructing these Strings from network bytes is a large fraction of total execution time. Any increase in the

Re: RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

I support Peter's initiative and am willing to help review if we have general consensus about the direction. >From superficial review: +int nread = randomStream.read(bytes); +if (nread != bytes.length) { +throw new InternalError("Short read from

Re: RFR 8060068 : Remove the static initializer block from DriverManager

Hi Mandy, On Dec 2, 2014, at 5:10 PM, Mandy Chung wrote: > Hi Bernd, > > On 12/2/14 1:49 PM, Bernd Eckenfels wrote: >> Hello, >> >> just want to add two somewhat related observations: >> >> we have a virtual JDBC driver which maps back to an real driver (or to >> an Pool/Datasource which uses

Re: More memory-efficient internal representation for Strings: call for more data

Hi Vitaly, Please read the JEP proposal. String/char[] fusion (that's what you are describing) is out of scope for this work. Baby steps. Careful baby steps. -Aleksey. On 03.12.2014 01:13, Vitaly Davidovich wrote: > Any consideration towards removing the char[] (or byte[]) indirection > altogeth

Re: More memory-efficient internal representation for Strings: call for more data

Any consideration towards removing the char[] (or byte[]) indirection altogether? .NET for example stores the bytes inline with the instance. Sent from my phone On Dec 2, 2014 4:59 PM, "Aleksey Shipilev" wrote: > Hi, > > As you may already know, we are looking into more memory efficient > repres

Re: RFR 8060068 : Remove the static initializer block from DriverManager

Bernd, Thank you for your input On Dec 2, 2014, at 4:49 PM, Bernd Eckenfels wrote: > Hello, > > just want to add two somewhat related observations: > > we have a virtual JDBC driver which maps back to an real driver (or to > an Pool/Datasource which uses a real driver. This is to allow > JDBC

Re: RFR 8060068 : Remove the static initializer block from DriverManager

Hi Bernd, On 12/2/14 1:49 PM, Bernd Eckenfels wrote: Hello, just want to add two somewhat related observations: we have a virtual JDBC driver which maps back to an real driver (or to an Pool/Datasource which uses a real driver. This is to allow JDBC URLs to work in different environments with

More memory-efficient internal representation for Strings: call for more data

Hi, As you may already know, we are looking into more memory efficient representation for Strings: https://bugs.openjdk.java.net/browse/JDK-8054307 As part of preliminary performance work for this JEP, we have to collect the empirical data on usual characteristics of Strings and char[]-s normal

Re: RFR 8060068 : Remove the static initializer block from DriverManager

Hello, just want to add two somewhat related observations: we have a virtual JDBC driver which maps back to an real driver (or to an Pool/Datasource which uses a real driver. This is to allow JDBC URLs to work in different environments with no config. (Thats is not the nices solution, but after w

Re: RFR 8060068 : Remove the static initializer block from DriverManager

On Dec 2, 2014, at 4:12 PM, Mandy Chung wrote: > On 12/2/14 12:30 PM, Lance Andersen wrote: >> >>> So it may be better to have a getter method to ensure driver classes are >>> loaded as well as return the registeredDrivers copy-on-write-arraylist. >>> i.e. you could rename initDriversIfNeeded

Re: RFR 8060068 : Remove the static initializer block from DriverManager

On 12/2/14 12:30 PM, Lance Andersen wrote: So it may be better to have a getter method to ensure driver classes are loaded as well as return the registeredDrivers copy-on-write-arraylist. i.e. you could rename initDriversIfNeeded to getRegisteredDrivers and replace for(DriverInfo aDriver : r

Re: RFR: 8065991: LogManager unecessarily calls JavaAWTAccess from within a critical section

On 12/2/14 12:26 PM, Daniel Fuchs wrote: Hi Mandy, On 02/12/14 20:24, Mandy Chung wrote: Hi Daniel, On 11/26/14 9:11 AM, Daniel Fuchs wrote: Hi, Please find below a patch for: 8065991: LogManager unecessarily calls JavaAWTAccess from within a critical section https://bugs.openjdk.j

Help us with choosing issue BG JUG adopt hackathon

Hello core libs developers! I am Ivan from the Bulgarian Java User Group. We are adopting OpenJDK for quite some time in our JUG. So far we have done some sessions in our community as well as on conferences in Bulgaria and neighboring countries, where we just talked about the project and the adopt

Re: RFR 8060068 : Remove the static initializer block from DriverManager

Hi Mandy, Thank you for the review, please see below On Dec 2, 2014, at 2:56 PM, Mandy Chung wrote: > On 12/1/14 8:52 AM, Lance Andersen wrote: >> Hi all, >> >> Looking for a review for this change to DriverManager to reduce the >> possibility on a deadlock on . that I have been discussing wi

Re: RFR: 8065991: LogManager unecessarily calls JavaAWTAccess from within a critical section

Hi Mandy, On 02/12/14 20:24, Mandy Chung wrote: Hi Daniel, On 11/26/14 9:11 AM, Daniel Fuchs wrote: Hi, Please find below a patch for: 8065991: LogManager unecessarily calls JavaAWTAccess from within a critical section https://bugs.openjdk.java.net/browse/JDK-8065991 Webrev: http:/

Re: RFR 8060068 : Remove the static initializer block from DriverManager

On 12/1/14 8:52 AM, Lance Andersen wrote: Hi all, Looking for a review for this change to DriverManager to reduce the possibility on a deadlock on . that I have been discussing with Mandy. The change removes the static initializer block as well as the synchronized keyword from registerDriver

Re: RFR: 8065991: LogManager unecessarily calls JavaAWTAccess from within a critical section

Hi Daniel, On 11/26/14 9:11 AM, Daniel Fuchs wrote: Hi, Please find below a patch for: 8065991: LogManager unecessarily calls JavaAWTAccess from within a critical section https://bugs.openjdk.java.net/browse/JDK-8065991 Webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8065991/webrev

Re: RFR 8060068 : Remove the static initializer block from DriverManager

Hi Stuart, On Dec 2, 2014, at 1:35 PM, Stuart Marks wrote: > Hi Lance, > > Overall, looks fine. Thank you for the review > > Typo "earleir" at line 569. fixed > > I agree with having two separate init methods, since initDriversIfNeeded() > conveniently separates the (safe) double-checked lo

Re: RFR 8060068 : Remove the static initializer block from DriverManager

Hi Lance, Overall, looks fine. Typo "earleir" at line 569. I agree with having two separate init methods, since initDriversIfNeeded() conveniently separates the (safe) double-checked locking idiom from the actual initialization legwork in loadInitialDrivers(). I'm not entirely convinced, ho

Re: RFR: 8065870 Update JAX-WS RI integration to latest version (2.2.11-b141124.1933)

Great, this sounds fine. s'marks On 12/2/14 6:03 AM, Miroslav Kos wrote: Hi Stuart, minor stuff like invalid characters and copyright years I can fix before push, the rest will leave for next integration which should be soon. Thanks! Miran On 01/12/14 20:35, Stuart Marks wrote: Hi Miran,

Re: RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

On 02/12/2014 16:42, Peter Levart wrote: : Here's a proof of concept for an API that just delegates to system-provided "cryptographically secure" (as declared by the system(s)) pseudo random number generator: http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.01/ The API looks

Re: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support eviction

On Dec 2, 2014, at 5:20 PM, Vladimir Ivanov wrote: > Thanks, Paul! > Updated webrev in place. +1. Paul.

Re: Packing 2 data points into 1 field in ThreadPoolExecutor

Thanks for all responses. All this is much clearer now. Am I right that all this state packing is for better performance only and the same behaviour can be achieved by using explicit locks? > On Dec 2, 2014, at 05:32, David Holmes wrote: > > On 2/12/2014 3:44 AM, Alex Yursha wrote: >> 1. Do yo

Re: RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

On Dec 2, 2014, at 5:42 PM, Peter Levart wrote: > On 12/02/2014 11:02 AM, Paul Sandoz wrote: >> Hi, >> >> Please find below a patch to remove the networking code computing a seed in >> ThreadLocal/SplittableRandom. >> >> We thought it a good idea at the time :-) but subsequently on certain >

Re: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support eviction

Thanks, Paul! Updated webrev in place. On Dec 1, 2014, at 5:58 PM, Vladimir Ivanov wrote: http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8057020 That LambdaFormEditor.putInCache method just got more gnarly :-) Generally looks good. In sr

Re: RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

Hi Paul, Looks fine to me also. Thanks, Roger On 12/2/2014 5:02 AM, Paul Sandoz wrote: Hi, Please find below a patch to remove the networking code computing a seed in ThreadLocal/SplittableRandom. We thought it a good idea at the time :-) but subsequently on certain platforms this results

Re: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support eviction

On Dec 1, 2014, at 5:58 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8057020 > That LambdaFormEditor.putInCache method just got more gnarly :-) Generally looks good. In src/java.base/share/classes/java/lang/i

Re: RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

On 12/02/2014 11:02 AM, Paul Sandoz wrote: Hi, Please find below a patch to remove the networking code computing a seed in ThreadLocal/SplittableRandom. We thought it a good idea at the time :-) but subsequently on certain platforms this results in very high initalization costs that can propa

Re: RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

Thanks for doing this Paul. Looks good ( with Alan and Doug’s comments ). -Chris. On 2 Dec 2014, at 10:02, Paul Sandoz wrote: > Hi, > > Please find below a patch to remove the networking code computing a seed in > ThreadLocal/SplittableRandom. > > We thought it a good idea at the time :-) bu

Re: Review request for JDK-8051536: Convert JAXP function tests: javax.xml.parsers to jtreg(testng) tests

Hi Frank, I think this looks good overall. I might suggest that you consider utilizing the @BeforeMethod methods further, For example is SAXParserTest03.java you could move SAXParserFactory spf = SAXParserFactory.newInstance(); spf.setValidating(true); to your @BeforeMethod, or consider usin

Re: RFR 8065998: Avoid use of _ as a one-character identifier

Thanks to all for the comments! Jan On 2.12.2014 11:15, Alan Bateman wrote: On 01/12/2014 13:37, Jan Lahoda wrote: : In TypeCheckMicroBenchmark then "ignore" is might be a misleading too given that the ArrayStoreException causes a CCE to be thrown. I've updated the patch to use "expected"

Re: RFR: 8065870 Update JAX-WS RI integration to latest version (2.2.11-b141124.1933)

Hi Stuart, minor stuff like invalid characters and copyright years I can fix before push, the rest will leave for next integration which should be soon. Thanks! Miran On 01/12/14 20:35, Stuart Marks wrote: Hi Miran, I'm pretty distant from the JAX-WS code, but I looked through all of the

Re: RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

On Dec 2, 2014, at 1:17 PM, Doug Lea wrote: > On 12/02/2014 05:02 AM, Paul Sandoz wrote: >> Hi, >> >> Please find below a patch to remove the networking code computing a seed in >> ThreadLocal/SplittableRandom. >> > > Thanks for pushing this through. > (I also adjusted 166 sources accordingl

Re: RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

On 12/02/2014 05:02 AM, Paul Sandoz wrote: Hi, Please find below a patch to remove the networking code computing a seed in ThreadLocal/SplittableRandom. Thanks for pushing this through. (I also adjusted 166 sources accordingly.) One more touch-up for SplittableRandom is to remove mention of

Re: [concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

On Dec 2, 2014, at 1:58 AM, Doug Lea wrote: > On 12/01/2014 03:46 PM, Martin Buchholz wrote: >> David, Paul (i.e. Reviewers) and Doug, >> >> I'd like to commit corrections so we make progress. > > The current one looks OK to me. > (http://cr.openjdk.java.net/~martin/webrevs/openjdk9/fence-intr

Re: RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

On Dec 2, 2014, at 11:10 AM, Alan Bateman wrote: > On 02/12/2014 10:02, Paul Sandoz wrote: >> Hi, >> >> Please find below a patch to remove the networking code computing a seed in >> ThreadLocal/SplittableRandom. >> >> We thought it a good idea at the time :-) but subsequently on certain >>

Re: RFR - 8065552: setAccessible(true) on fields of Class may throw a SecurityException

On 01/12/2014 21:09, Seán Coffey wrote: On 01/12/2014 18:54, Daniel Fuchs wrote: on the test side would it be worth testing all public classes available (e.g in rt.jar ?) to ensure that Field.setAccessible works as expected and that we don't hit this issue again ? It might be some what of a hea

Re: RFR 8065998: Avoid use of _ as a one-character identifier

On 01/12/2014 13:37, Jan Lahoda wrote: : In TypeCheckMicroBenchmark then "ignore" is might be a misleading too given that the ArrayStoreException causes a CCE to be thrown. I've updated the patch to use "expected" where the exception appears to be expected and "unused" where exception appea

Re: RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

On 02/12/2014 10:02, Paul Sandoz wrote: Hi, Please find below a patch to remove the networking code computing a seed in ThreadLocal/SplittableRandom. We thought it a good idea at the time :-) but subsequently on certain platforms this results in very high initalization costs that can propagat

RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

Hi, Please find below a patch to remove the networking code computing a seed in ThreadLocal/SplittableRandom. We thought it a good idea at the time :-) but subsequently on certain platforms this results in very high initalization costs that can propagate to other classes such as ConcurrentSkip

Re: RFR: 8065172: More core reflection final and volatile annotations

On Nov 25, 2014, at 3:06 AM, Martin Buchholz wrote: > I tried to address all the known problems in sun/reflect (except for > the performance ones), including the ones in Peter's webrev (although > it now looks quite different). > > I broke down and switched to using AtomicReferenceFieldUpdaters

Re: Packing 2 data points into 1 field in ThreadPoolExecutor

On 2/12/2014 4:51 PM, Alex Yursha wrote: Thanks for all responses. All this is much clearer now. Am I right that all this state packing is for better performance only and the same behaviour can be achieved by using explicit locks? Sure. David On Dec 2, 2014, at 05:32, David Holmes wrote:

Re: Library enhancement proposal for copying data from/to Reader/Writer InputStream/OutputStream

Finally got the time to search thru the JDK codebase - at the moment JDK8 due the lack of a working Netbeans Project for JDK9 (I will try to make that working again) >> What usage would you actually search in the OpenJDK code base? > > We're talking about copying with provided buffer, right? >

Re: Better NewIO2 file system implementation for AIX platform

Hi Deven, I've just realized that you still use the Linux functions fgetxattr, fsetxattr, ... I don't think this will ever work on AIX. Please use the corresponding functions from (i.e. getea, setea, removeea). Thanks, Volker On Mon, Dec 1, 2014 at 7:38 PM, Volker Simonis wrote: > On Mon, Dec