Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

On 01/21/2014 03:22 AM, David Holmes wrote: Hi Peter, I do not see Cleaner being loaded prior to the main class on either Windows or Linux. Which platform are you on? Did you see it loaded before the main class or as part of executing it? Before. The main class is empty: public class Test

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

Hi Peter, I do not see Cleaner being loaded prior to the main class on either Windows or Linux. Which platform are you on? Did you see it loaded before the main class or as part of executing it? Also, it is not that I think ReferenceHandler is responsible for reporting OOME, but that it is r

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

> On 20 Jan 2014, at 15:18, Paul Sandoz wrote: > > >> On Jan 20, 2014, at 3:18 PM, Chris Hegarty 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 em

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

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 backed streams (e.g. map Path -> Stream for lines of a file). The following patch

Re: JDK 9 RFR for 8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281

On 1/20/2014 10:35 AM, Daniel Fuchs wrote: On 1/20/14 7:17 PM, Mandy Chung wrote: On 1/17/2014 6:51 AM, Daniel Fuchs wrote: Hi, Please find below a webrev for: 8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281 https://bugs.openjdk.java.net/browse/JDK-8031980

Re: JDK 9 RFR for 8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281

On 1/20/14 7:17 PM, Mandy Chung wrote: On 1/17/2014 6:51 AM, Daniel Fuchs wrote: Hi, Please find below a webrev for: 8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281 https://bugs.openjdk.java.net/browse/JDK-8031980

Re: JDK 9 RFR for 8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281

On 1/17/2014 6:51 AM, Daniel Fuchs wrote: Hi, Please find below a webrev for: 8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281 https://bugs.openjdk.java.net/browse/JDK-8031980 The new test looks reasonable.

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

On Jan 16, 2014, at 7:08 PM, Xueming Shen 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 > case mapping hand

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On 20/01/2014 16:29, Volker Simonis wrote: : @Alan: on the other hand, the bulk integration from ppc-aix-port/stage-9 to jdk9/dev is planned for next week anyway, so maybe you could wait until that happens? In that case then ignore my request, I assumed it would not be pushed to jdk9/dev until

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On Mon, Jan 20, 2014 at 4:24 PM, Alan Bateman wrote: > On 20/01/2014 13:45, Volker Simonis wrote: >> >> : >> Hi everybody, >> >> so here's the second version of this webrev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/ > > This looks okay to me. Thanks. > > The typo ("legel" -> "

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

On Jan 20, 2014, at 3:18 PM, Chris Hegarty 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 was better, but t

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On 20/01/2014 13:45, Volker Simonis wrote: : Hi everybody, so here's the second version of this webrev: http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/ This looks okay to me. The typo ("legel" -> "legal") still exists in zip_util.c and maybe that can be fixed before you push this (no

Re: RFR [8027348] (process) Enhancement of handling async close of ProcessInputStream

Hello everybody! Can I consider this change approved for jdk9? Thanks in advance, Ivan Gerasimov On 20.11.2013 0:56, Martin Buchholz wrote: Ivan, Thanks for taking ownership of my proposed change. Looks good to me! (I can't actually push changes like this myself because I only do Linux thes

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

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 was better, but that could be just me. -Chris. On 20/01/14 10:38, Paul Sando

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On Mon, Jan 20, 2014 at 12:41 PM, Alan Bateman wrote: > On 20/01/2014 09:59, Volker Simonis wrote: >> >> : >> Hi Alan, >> >> yes, that's interesting. Sounds like a very similar problem on Mac. >> >> I would suggest the following: >> >> I cut out the "Async Close AIX FIX" stuff from this change (i.

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On 20/01/2014 09:59, Volker Simonis wrote: : Hi Alan, yes, that's interesting. Sounds like a very similar problem on Mac. I would suggest the following: I cut out the "Async Close AIX FIX" stuff from this change (i.e. "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests"

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

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 backed streams (e.g. map Path -> Stream for lines of a file). The following patch fixes that omission in the docs: https://b

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On Fri, Jan 17, 2014 at 10:15 PM, Volker Simonis wrote: > On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman > wrote: >> On 14/01/2014 08:40, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following changes for the ppc-aix-port >>> stage/stage-9 repositories (the changes are p

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

On Jan 17, 2014, at 10:10 PM, Mandy Chung 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 typo. > Lo

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

On 01/20/2014 09:00 AM, Peter Levart wrote: On 01/20/2014 02:51 AM, David Holmes wrote: Hi Peter, On 17/01/2014 11:24 PM, Peter Levart wrote: On 01/17/2014 02:13 PM, Peter Levart wrote: // Fast path for cleaners boolean isCleaner = false; try { isCleaner = r instanceof Cleaner; } catch (Out

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

On 01/20/2014 02:51 AM, David Holmes wrote: Hi Peter, On 17/01/2014 11:24 PM, Peter Levart wrote: On 01/17/2014 02:13 PM, Peter Levart wrote: // Fast path for cleaners boolean isCleaner = false; try { isCleaner = r instanceof Cleaner; } catch (OutofMemoryError oome) { continue; } if (isCl