From christoph.langer at sap.com  Mon Jul  3 08:17:13 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 3 Jul 2017 08:17:13 +0000
Subject: 8182743: Ineffective use of volatile hurts performance of
 Charset.atBugLevel()
In-Reply-To: <OFFAA5395C.D74BB21D-ON4925814F.006552C5-4925814F.0065B63E@notes.na.collabserv.com>
References: <OF2AAD04AE.D1E25224-ON4925814C.001B6E1D-4925814C.001CA256@notes.na.collabserv.com>
 <3e6fb1a5429549398a98da86f4a3bc49@sap.com>
 <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com>
 <a9178440-aea1-c2aa-7aab-77536a972dda@oracle.com>
 <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com>
 <9a235816b1544dd587a1e6d2268e6407@sap.com>
 <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com>
 <efd1ec13120c48ecb3a977dc244d6250@sap.com>
 <OFBFC52ED9.A91AAECA-ON4925814D.0035FF61-4925814D.0036DC3B@notes.na.collabserv.com>
 <254e340e1a084a57bd77c1a99884ce1b@sap.com>
 <OF7B52711E.FAF07D7E-ON4925814E.0066EBA0-4925814E.00676717@notes.na.collabserv.com>
 <dceda7ca-e2dd-63bd-e7a2-518862ed6535@oracle.com>
 <OFFAA5395C.D74BB21D-ON4925814F.006552C5-4925814F.0065B63E@notes.na.collabserv.com>
Message-ID: <af2789b9dbed4b5aaac9a092d1ac93e9@sap.com>

Hi,

I've pushed to JDK10 now: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/7a2bc0a80087

What do you think, shall we try to downport a fix to JDK9 updates and JDK8 updates, which simply removes the volatile as we can't bring this behavior changing fix down? 

Thanks
Christoph

> -----Original Message-----
> From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com]
> Sent: Freitag, 30. Juni 2017 20:31
> To: Se?n Coffey <sean.coffey at oracle.com>
> Cc: Langer, Christoph <christoph.langer at sap.com>; core-libs-dev <core-libs-
> dev at openjdk.java.net>; nio-dev at openjdk.java.net; ppc-aix-port-
> dev at openjdk.java.net
> Subject: Re: 8182743: Ineffective use of volatile hurts performance of
> Charset.atBugLevel()
> 
> Hi Sean,
> 
> Thank you for your comments.
> 
> I fixed the copyright and updated webrev:
> 
> http://cr.openjdk.java.net/~horii/8182743/webrev.03/
> 
> 
> > * The bug ID referenced in mail/webrev links is wrong. It should be
> > 8182743 ?
> 
> Yes, they should be 8182743.  I fixed both.
> 
> 
> Regards,
> Ogata
> 
> 
> Se?n Coffey <sean.coffey at oracle.com> wrote on 2017/06/30 23:57:25:
> 
> > From: Se?n Coffey <sean.coffey at oracle.com>
> > To: Kazunori Ogata <OGATAK at jp.ibm.com>, "Langer, Christoph"
> > <christoph.langer at sap.com>
> > Cc: "ppc-aix-port-dev at openjdk.java.net" <ppc-aix-port-
> > dev at openjdk.java.net>, core-libs-dev <core-libs-dev at openjdk.java.net>,
> > "nio-dev at openjdk.java.net" <nio-dev at openjdk.java.net>
> > Date: 2017/06/30 23:57
> > Subject: Re: 8179527:(8182743?) Ineffective use of volatile hurts
> > performance of Charset.atBugLevel()
> >
> > Ogata,
> >
> > minor comments from me.
> >
> > * The bug ID referenced in mail/webrev links is wrong. It should be
> > 8182743 ?
> > * The copyright change in Charset-X-Coder.java.template is the wrong
> > format. You can simply replace 2013 with 2017.
> >
> > Regards,
> > Sean.
> >
> > On 29/06/17 19:49, Kazunori Ogata wrote:
> > > Hi Christoph,
> > >
> > > I updated webrev:
> http://cr.openjdk.java.net/~horii/8179527/webrev.02/
> > >
> > > This one includes changes in tests.  I removed all @run and @build
> > > directives in the tests because those after removing "@run
> main/othervm
> > > -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" are the same as the
> default
> > > ones.  I checked the modified tests passed.
> > >
> > > I also fixed the copyright lines.
> > >
> > >
> > > Regards,
> > > Ogata
> > >
> > >
> > > "Langer, Christoph" <christoph.langer at sap.com> wrote on 2017/06/28
> > > 21:04:36:
> > >
> > >> From: "Langer, Christoph" <christoph.langer at sap.com>
> > >> To: Kazunori Ogata <OGATAK at jp.ibm.com>
> > >> Cc: Alan Bateman <Alan.Bateman at oracle.com>, Claes Redestad
> > >> <claes.redestad at oracle.com>, core-libs-dev <core-libs-
> > >> dev at openjdk.java.net>, "nio-dev at openjdk.java.net" <nio-
> > >> dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net"
> > > <ppc-aix-port-
> > >> dev at openjdk.java.net>
> > >> Date: 2017/06/28 21:04
> > >> Subject: RE: 8179527: Ineffective use of volatile hurts performance
> of
> > >> Charset.atBugLevel()
> > >>
> > >> Hi Ogata,
> > >>
> > >>>> remove the second run with -Dsun.nio.cs.bugLevel=1.4
> > >>> How can I do this?  Is it sufficient to remove the following line at
> > > the
> > >>> beginning of the file?: "@run main/othervm -Dsun.nio.cs.bugLevel=1.4
> > >>> EmptyCharsetName"
> > >> Yes, this line should be removed. Currently there are two @run
> > > directives
> > >> which cause running the testcase twice. Once in normal mode and once
> > > with
> > >> bugLevel set to 1.4. So, if "sun.nio.cs.bugLevel" ought to be removed
> > > then
> > >> the second iteration of the test is obsolete. And then one should
> > > probably
> > >> remove the whole "compat" handling in the test.
> > >>
> > >> Best regards
> > >> Christoph
> > >>
> > >
> >
> 


From OGATAK at jp.ibm.com  Mon Jul  3 08:28:46 2017
From: OGATAK at jp.ibm.com (Kazunori Ogata)
Date: Mon, 3 Jul 2017 17:28:46 +0900
Subject: 8182743: Ineffective use of volatile hurts performance of
 Charset.atBugLevel()
In-Reply-To: <af2789b9dbed4b5aaac9a092d1ac93e9@sap.com>
References: <OF2AAD04AE.D1E25224-ON4925814C.001B6E1D-4925814C.001CA256@notes.na.collabserv.com>
 <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com>
 <a9178440-aea1-c2aa-7aab-77536a972dda@oracle.com>
 <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com>
 <9a235816b1544dd587a1e6d2268e6407@sap.com>
 <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com>
 <efd1ec13120c48ecb3a977dc244d6250@sap.com>
 <OFBFC52ED9.A91AAECA-ON4925814D.0035FF61-4925814D.0036DC3B@notes.na.collabserv.com>
 <254e340e1a084a57bd77c1a99884ce1b@sap.com>
 <OF7B52711E.FAF07D7E-ON4925814E.0066EBA0-4925814E.00676717@notes.na.collabserv.com>
 <dceda7ca-e2dd-63bd-e7a2-518862ed6535@oracle.com>
 <OFFAA5395C.D74BB21D-ON4925814F.006552C5-4925814F.0065B63E@notes.na.collabserv.com>
 <af2789b9dbed4b5aaac9a092d1ac93e9@sap.com>
Message-ID: <OFC2405516.267F666A-ON49258152.002DD379-49258152.002E97C5@notes.na.collabserv.com>

Hi Christoph,

Thank you very much for your help!

For JDK9 updates and JDK8 updates, it is desirable if we can back port the 
removal of volatile.  What should I do for it?


Regards,
Ogata



From:   "Langer, Christoph" <christoph.langer at sap.com>
To:     Kazunori Ogata <OGATAK at jp.ibm.com>, "nio-dev at openjdk.java.net" 
<nio-dev at openjdk.java.net>
Cc:     core-libs-dev <core-libs-dev at openjdk.java.net>
Date:   2017/07/03 17:17
Subject:        RE: 8182743: Ineffective use of volatile hurts performance 
of Charset.atBugLevel()



Hi,

I've pushed to JDK10 now: 
http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/7a2bc0a80087

What do you think, shall we try to downport a fix to JDK9 updates and JDK8 
updates, which simply removes the volatile as we can't bring this behavior 
changing fix down? 

Thanks
Christoph

> -----Original Message-----
> From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com]
> Sent: Freitag, 30. Juni 2017 20:31
> To: Se?n Coffey <sean.coffey at oracle.com>
> Cc: Langer, Christoph <christoph.langer at sap.com>; core-libs-dev 
<core-libs-
> dev at openjdk.java.net>; nio-dev at openjdk.java.net; ppc-aix-port-
> dev at openjdk.java.net
> Subject: Re: 8182743: Ineffective use of volatile hurts performance of
> Charset.atBugLevel()
> 
> Hi Sean,
> 
> Thank you for your comments.
> 
> I fixed the copyright and updated webrev:
> 
> http://cr.openjdk.java.net/~horii/8182743/webrev.03/
> 
> 
> > * The bug ID referenced in mail/webrev links is wrong. It should be
> > 8182743 ?
> 
> Yes, they should be 8182743.  I fixed both.
> 
> 
> Regards,
> Ogata
> 
> 
> Se?n Coffey <sean.coffey at oracle.com> wrote on 2017/06/30 23:57:25:
> 
> > From: Se?n Coffey <sean.coffey at oracle.com>
> > To: Kazunori Ogata <OGATAK at jp.ibm.com>, "Langer, Christoph"
> > <christoph.langer at sap.com>
> > Cc: "ppc-aix-port-dev at openjdk.java.net" <ppc-aix-port-
> > dev at openjdk.java.net>, core-libs-dev <core-libs-dev at openjdk.java.net>,
> > "nio-dev at openjdk.java.net" <nio-dev at openjdk.java.net>
> > Date: 2017/06/30 23:57
> > Subject: Re: 8179527:(8182743?) Ineffective use of volatile hurts
> > performance of Charset.atBugLevel()
> >
> > Ogata,
> >
> > minor comments from me.
> >
> > * The bug ID referenced in mail/webrev links is wrong. It should be
> > 8182743 ?
> > * The copyright change in Charset-X-Coder.java.template is the wrong
> > format. You can simply replace 2013 with 2017.
> >
> > Regards,
> > Sean.
> >
> > On 29/06/17 19:49, Kazunori Ogata wrote:
> > > Hi Christoph,
> > >
> > > I updated webrev:
> http://cr.openjdk.java.net/~horii/8179527/webrev.02/
> > >
> > > This one includes changes in tests.  I removed all @run and @build
> > > directives in the tests because those after removing "@run
> main/othervm
> > > -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" are the same as the
> default
> > > ones.  I checked the modified tests passed.
> > >
> > > I also fixed the copyright lines.
> > >
> > >
> > > Regards,
> > > Ogata
> > >
> > >
> > > "Langer, Christoph" <christoph.langer at sap.com> wrote on 2017/06/28
> > > 21:04:36:
> > >
> > >> From: "Langer, Christoph" <christoph.langer at sap.com>
> > >> To: Kazunori Ogata <OGATAK at jp.ibm.com>
> > >> Cc: Alan Bateman <Alan.Bateman at oracle.com>, Claes Redestad
> > >> <claes.redestad at oracle.com>, core-libs-dev <core-libs-
> > >> dev at openjdk.java.net>, "nio-dev at openjdk.java.net" <nio-
> > >> dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net"
> > > <ppc-aix-port-
> > >> dev at openjdk.java.net>
> > >> Date: 2017/06/28 21:04
> > >> Subject: RE: 8179527: Ineffective use of volatile hurts performance
> of
> > >> Charset.atBugLevel()
> > >>
> > >> Hi Ogata,
> > >>
> > >>>> remove the second run with -Dsun.nio.cs.bugLevel=1.4
> > >>> How can I do this?  Is it sufficient to remove the following line 
at
> > > the
> > >>> beginning of the file?: "@run main/othervm 
-Dsun.nio.cs.bugLevel=1.4
> > >>> EmptyCharsetName"
> > >> Yes, this line should be removed. Currently there are two @run
> > > directives
> > >> which cause running the testcase twice. Once in normal mode and 
once
> > > with
> > >> bugLevel set to 1.4. So, if "sun.nio.cs.bugLevel" ought to be 
removed
> > > then
> > >> the second iteration of the test is obsolete. And then one should
> > > probably
> > >> remove the whole "compat" handling in the test.
> > >>
> > >> Best regards
> > >> Christoph
> > >>
> > >
> >
> 





From amy.lu at oracle.com  Tue Jul  4 02:13:56 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 4 Jul 2017 10:13:56 +0800
Subject: JDK 10 RFR of JDK-8183512: Remove intermittent key from nio test
 Transfer4GBFile.java TransferTo6GBFile.java and StressLoopback.java
Message-ID: <48c7b02e-c4a9-ada5-d266-6586d8c8d0c7@oracle.com>

java/nio/channels/FileChannel/Transfer4GBFile.java
java/nio/channels/FileChannel/TransferTo6GBFile.java
java/nio/channels/AsynchronousSocketChannel/StressLoopback.java

Tests were failing intermittently and the related bugs (JDK-8176895, 
JDK-8177550 and JDK-8171347) have been fixed, no open bugs (no failure 
reported).

This patch is to remove @key intermittent from these tests.

bug: https://bugs.openjdk.java.net/browse/JDK-8183512
webrev: http://cr.openjdk.java.net/~amlu/8183512/webrev.00/

Thanks,
Amy


--- old/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java	2017-07-04 10:05:50.000000000 +0800
+++ new/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java	2017-07-04 10:05:50.000000000 +0800
@@ -26,7 +26,7 @@
   * @summary Stress test connections through the loopback interface
   * @run main StressLoopback
   * @run main/othervm -Djdk.net.useFastTcpLoopback StressLoopback
- * @key randomness intermittent
+ * @key randomness
   */
  
  import java.nio.ByteBuffer;
--- old/test/java/nio/channels/FileChannel/Transfer4GBFile.java	2017-07-04 10:05:51.000000000 +0800
+++ new/test/java/nio/channels/FileChannel/Transfer4GBFile.java	2017-07-04 10:05:51.000000000 +0800
@@ -23,7 +23,6 @@
  
  /* @test
   * @bug 4638365
- * @key intermittent
   * @summary Test FileChannel.transferFrom and transferTo for 4GB files
   * @run testng/timeout=300 Transfer4GBFile
   */
--- old/test/java/nio/channels/FileChannel/TransferTo6GBFile.java	2017-07-04 10:05:52.000000000 +0800
+++ new/test/java/nio/channels/FileChannel/TransferTo6GBFile.java	2017-07-04 10:05:51.000000000 +0800
@@ -23,7 +23,6 @@
  
  /* @test
   * @bug 6253145
- * @key intermittent
   * @summary Test FileChannel.transferTo with file positions up to 8GB
   * @run testng/timeout=300 TransferTo6GBFile
   */



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170704/5a09df06/attachment.html>

From amy.lu at oracle.com  Tue Jul  4 02:51:19 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 4 Jul 2017 10:51:19 +0800
Subject: JDK 10 RFR of JDK-8183512: Remove intermittent key from nio test
 Transfer4GBFile.java TransferTo6GBFile.java and StressLoopback.java
In-Reply-To: <48c7b02e-c4a9-ada5-d266-6586d8c8d0c7@oracle.com>
References: <48c7b02e-c4a9-ada5-d266-6586d8c8d0c7@oracle.com>
Message-ID: <ece0d071-1f15-8824-7ce6-e20872e9308d@oracle.com>

Including core-libs-dev

On 7/4/17 10:13 AM, Amy Lu wrote:
> java/nio/channels/FileChannel/Transfer4GBFile.java
> java/nio/channels/FileChannel/TransferTo6GBFile.java
> java/nio/channels/AsynchronousSocketChannel/StressLoopback.java
>
> Tests were failing intermittently and the related bugs (JDK-8176895, 
> JDK-8177550 and JDK-8171347) have been fixed, no open bugs (no failure 
> reported).
>
> This patch is to remove @key intermittent from these tests.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8183512
> webrev: http://cr.openjdk.java.net/~amlu/8183512/webrev.00/
>
> Thanks,
> Amy
>
>
> --- old/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java	2017-07-04 10:05:50.000000000 +0800
> +++ new/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java	2017-07-04 10:05:50.000000000 +0800
> @@ -26,7 +26,7 @@
>    * @summary Stress test connections through the loopback interface
>    * @run main StressLoopback
>    * @run main/othervm -Djdk.net.useFastTcpLoopback StressLoopback
> - * @key randomness intermittent
> + * @key randomness
>    */
>   
>   import java.nio.ByteBuffer;
> --- old/test/java/nio/channels/FileChannel/Transfer4GBFile.java	2017-07-04 10:05:51.000000000 +0800
> +++ new/test/java/nio/channels/FileChannel/Transfer4GBFile.java	2017-07-04 10:05:51.000000000 +0800
> @@ -23,7 +23,6 @@
>   
>   /* @test
>    * @bug 4638365
> - * @key intermittent
>    * @summary Test FileChannel.transferFrom and transferTo for 4GB files
>    * @run testng/timeout=300 Transfer4GBFile
>    */
> --- old/test/java/nio/channels/FileChannel/TransferTo6GBFile.java	2017-07-04 10:05:52.000000000 +0800
> +++ new/test/java/nio/channels/FileChannel/TransferTo6GBFile.java	2017-07-04 10:05:51.000000000 +0800
> @@ -23,7 +23,6 @@
>   
>   /* @test
>    * @bug 6253145
> - * @key intermittent
>    * @summary Test FileChannel.transferTo with file positions up to 8GB
>    * @run testng/timeout=300 TransferTo6GBFile
>    */
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170704/d0150013/attachment.html>

From Alan.Bateman at oracle.com  Tue Jul  4 05:52:54 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 4 Jul 2017 06:52:54 +0100
Subject: JDK 10 RFR of JDK-8183512: Remove intermittent key from nio test
 Transfer4GBFile.java TransferTo6GBFile.java and StressLoopback.java
In-Reply-To: <48c7b02e-c4a9-ada5-d266-6586d8c8d0c7@oracle.com>
References: <48c7b02e-c4a9-ada5-d266-6586d8c8d0c7@oracle.com>
Message-ID: <6a49ce4d-5d6a-33b5-7500-d27907cf506e@oracle.com>

On 04/07/2017 03:13, Amy Lu wrote:
> java/nio/channels/FileChannel/Transfer4GBFile.java
> java/nio/channels/FileChannel/TransferTo6GBFile.java
> java/nio/channels/AsynchronousSocketChannel/StressLoopback.java
>
> Tests were failing intermittently and the related bugs (JDK-8176895, 
> JDK-8177550 and JDK-8171347) have been fixed, no open bugs (no failure 
> reported).
>
> This patch is to remove @key intermittent from these tests.
>
Looks fine.

From OGATAK at jp.ibm.com  Fri Jul  7 16:58:50 2017
From: OGATAK at jp.ibm.com (Kazunori Ogata)
Date: Sat, 8 Jul 2017 01:58:50 +0900
Subject: 8182743: Ineffective use of volatile hurts performance of
 Charset.atBugLevel()
In-Reply-To: <OFC2405516.267F666A-ON49258152.002DD379-49258152.002E977A@LocalDomain>
References: <OF2AAD04AE.D1E25224-ON4925814C.001B6E1D-4925814C.001CA256@notes.na.collabserv.com>
 <a9178440-aea1-c2aa-7aab-77536a972dda@oracle.com>
 <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com>
 <9a235816b1544dd587a1e6d2268e6407@sap.com>
 <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com>
 <efd1ec13120c48ecb3a977dc244d6250@sap.com>
 <OFBFC52ED9.A91AAECA-ON4925814D.0035FF61-4925814D.0036DC3B@notes.na.collabserv.com>
 <254e340e1a084a57bd77c1a99884ce1b@sap.com>
 <OF7B52711E.FAF07D7E-ON4925814E.0066EBA0-4925814E.00676717@notes.na.collabserv.com>
 <dceda7ca-e2dd-63bd-e7a2-518862ed6535@oracle.com>
 <OFFAA5395C.D74BB21D-ON4925814F.006552C5-4925814F.0065B63E@notes.na.collabserv.com>
 <af2789b9dbed4b5aaac9a092d1ac93e9@sap.com>
 <OFC2405516.267F666A-ON49258152.002DD379-49258152.002E977A@LocalDomain>
Message-ID: <OF337963DE.CBBE34E9-ON49258156.005D1F5A-49258156.005D4F00@notes.na.collabserv.com>

Hi all,

Any comment on downporting a fix to JDK9u and JDK8u, which simply removes 
volatile?


Regards,
Ogata

Kazunori Ogata/Japan/IBM wrote on 2017/07/03 17:28:54:

> From: Kazunori Ogata/Japan/IBM
> To: "Langer, Christoph" <christoph.langer at sap.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>, "nio-
> dev at openjdk.java.net" <nio-dev at openjdk.java.net>
> Date: 2017/07/03 17:28
> Subject: RE: 8182743: Ineffective use of volatile hurts performance of 
> Charset.atBugLevel()
> 
> Hi Christoph,
> 
> Thank you very much for your help!
> 
> For JDK9 updates and JDK8 updates, it is desirable if we can back port 
the
> removal of volatile.  What should I do for it?
> 
> Regards,
> Ogata
> 
> From: "Langer, Christoph" <christoph.langer at sap.com>
> To: Kazunori Ogata <OGATAK at jp.ibm.com>, "nio-dev at openjdk.java.net" <nio-
> dev at openjdk.java.net>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> Date: 2017/07/03 17:17
> Subject: RE: 8182743: Ineffective use of volatile hurts performance of 
> Charset.atBugLevel()
> 
> Hi,
> 
> I've pushed to JDK10 now: 
http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/
> 7a2bc0a80087
> 
> What do you think, shall we try to downport a fix to JDK9 updates and 
JDK8
> updates, which simply removes the volatile as we can't bring this 
behavior
> changing fix down? 
> 
> Thanks
> Christoph
> 
> > -----Original Message-----
> > From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com]
> > Sent: Freitag, 30. Juni 2017 20:31
> > To: Se?n Coffey <sean.coffey at oracle.com>
> > Cc: Langer, Christoph <christoph.langer at sap.com>; core-libs-dev 
<core-libs-
> > dev at openjdk.java.net>; nio-dev at openjdk.java.net; ppc-aix-port-
> > dev at openjdk.java.net
> > Subject: Re: 8182743: Ineffective use of volatile hurts performance of
> > Charset.atBugLevel()
> > 
> > Hi Sean,
> > 
> > Thank you for your comments.
> > 
> > I fixed the copyright and updated webrev:
> > 
> > http://cr.openjdk.java.net/~horii/8182743/webrev.03/
> > 
> > 
> > > * The bug ID referenced in mail/webrev links is wrong. It should be
> > > 8182743 ?
> > 
> > Yes, they should be 8182743.  I fixed both.
> > 
> > 
> > Regards,
> > Ogata
> > 
> > 
> > Se?n Coffey <sean.coffey at oracle.com> wrote on 2017/06/30 23:57:25:
> > 
> > > From: Se?n Coffey <sean.coffey at oracle.com>
> > > To: Kazunori Ogata <OGATAK at jp.ibm.com>, "Langer, Christoph"
> > > <christoph.langer at sap.com>
> > > Cc: "ppc-aix-port-dev at openjdk.java.net" <ppc-aix-port-
> > > dev at openjdk.java.net>, core-libs-dev 
<core-libs-dev at openjdk.java.net>,
> > > "nio-dev at openjdk.java.net" <nio-dev at openjdk.java.net>
> > > Date: 2017/06/30 23:57
> > > Subject: Re: 8179527:(8182743?) Ineffective use of volatile hurts
> > > performance of Charset.atBugLevel()
> > >
> > > Ogata,
> > >
> > > minor comments from me.
> > >
> > > * The bug ID referenced in mail/webrev links is wrong. It should be
> > > 8182743 ?
> > > * The copyright change in Charset-X-Coder.java.template is the wrong
> > > format. You can simply replace 2013 with 2017.
> > >
> > > Regards,
> > > Sean.
> > >
> > > On 29/06/17 19:49, Kazunori Ogata wrote:
> > > > Hi Christoph,
> > > >
> > > > I updated webrev:
> > http://cr.openjdk.java.net/~horii/8179527/webrev.02/
> > > >
> > > > This one includes changes in tests.  I removed all @run and @build
> > > > directives in the tests because those after removing "@run
> > main/othervm
> > > > -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" are the same as the
> > default
> > > > ones.  I checked the modified tests passed.
> > > >
> > > > I also fixed the copyright lines.
> > > >
> > > >
> > > > Regards,
> > > > Ogata
> > > >
> > > >
> > > > "Langer, Christoph" <christoph.langer at sap.com> wrote on 2017/06/28
> > > > 21:04:36:
> > > >
> > > >> From: "Langer, Christoph" <christoph.langer at sap.com>
> > > >> To: Kazunori Ogata <OGATAK at jp.ibm.com>
> > > >> Cc: Alan Bateman <Alan.Bateman at oracle.com>, Claes Redestad
> > > >> <claes.redestad at oracle.com>, core-libs-dev <core-libs-
> > > >> dev at openjdk.java.net>, "nio-dev at openjdk.java.net" <nio-
> > > >> dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net"
> > > > <ppc-aix-port-
> > > >> dev at openjdk.java.net>
> > > >> Date: 2017/06/28 21:04
> > > >> Subject: RE: 8179527: Ineffective use of volatile hurts 
performance
> > of
> > > >> Charset.atBugLevel()
> > > >>
> > > >> Hi Ogata,
> > > >>
> > > >>>> remove the second run with -Dsun.nio.cs.bugLevel=1.4
> > > >>> How can I do this?  Is it sufficient to remove the following 
line at
> > > > the
> > > >>> beginning of the file?: "@run main/othervm 
-Dsun.nio.cs.bugLevel=1.4
> > > >>> EmptyCharsetName"
> > > >> Yes, this line should be removed. Currently there are two @run
> > > > directives
> > > >> which cause running the testcase twice. Once in normal mode and 
once
> > > > with
> > > >> bugLevel set to 1.4. So, if "sun.nio.cs.bugLevel" ought to be 
removed
> > > > then
> > > >> the second iteration of the test is obsolete. And then one should
> > > > probably
> > > >> remove the whole "compat" handling in the test.
> > > >>
> > > >> Best regards
> > > >> Christoph
> > > >>
> > > >
> > >
> > 
> 



From brian.burkhalter at oracle.com  Mon Jul 10 20:24:24 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 10 Jul 2017 13:24:24 -0700
Subject: Is there any reason why the MacOS X port doesn't provide a
 UserDefinedFileAttributeView?
In-Reply-To: <ef8666e7-ce58-56df-a348-a9652a22446e@oracle.com>
References: <CADE8KM5GZ5GV1+xBrzxOtCHaqseGvwGZGj8e_LOys=Zuq+SAEQ@mail.gmail.com>
 <ef8666e7-ce58-56df-a348-a9652a22446e@oracle.com>
Message-ID: <49080AA6-4423-4C99-8BF4-8543CDBCA0F5@oracle.com>

On Jul 3, 2017, at 1:05 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 03/07/2017 20:39, Simon Spero wrote:
>> It seems like it ought  be relatively simple to add, since the API is not
>> too far off of Linux (with NO_FOLLOW as an option to syscall rather than a
>> separate entry point).
>> 
> This has been discussed on nio-dev once or twice. It wasn't in the original port from Apple and just hasn't bubbled to the top of anyone's list.

There is an enhancement request on file for this:

https://bugs.openjdk.java.net/browse/JDK-8030048

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170710/aee0d784/attachment.html>

From christoph.langer at sap.com  Thu Jul 13 10:29:53 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 13 Jul 2017 10:29:53 +0000
Subject: RFR(S): 8184330: Remove sun.nio.ch.Util.atBugLevel() either
 completely or at least get rid of volatile field bugLevel 
Message-ID: <36fe20638f7a4dfd80577d20570dea81@sap.com>

Hi,

after getting in the fix for JDK-8182743 [1] that removes "sun.nio.cs.bugLevel", I'm taking on Claes' suggestion [2]  to also tackle "sun.nio.ch.bugLevel". The bugLevel check is done to enable some JDK 1.4 compatible mode which I hope is safe to be dropped with JDK10. Unfortunately I didn't find the bug that introduced "sun.nio.cs.bugLevel", maybe someone can shed some more light on its history. I'm hoping that it's ok to remove this one as well. If there are no objections and I get it reviewed then I'll open a CSR request.

Bug: https://bugs.openjdk.java.net/browse/JDK-8184330
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8184330.0/

Thanks & Best regards
Christoph

[1] https://bugs.openjdk.java.net/browse/JDK-8182743
[2] http://mail.openjdk.java.net/pipermail/nio-dev/2017-June/004330.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170713/c9cd4472/attachment.html>

From christoph.langer at sap.com  Thu Jul 13 10:32:32 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 13 Jul 2017 10:32:32 +0000
Subject: 8182743: Ineffective use of volatile hurts performance of
 Charset.atBugLevel()
In-Reply-To: <OF337963DE.CBBE34E9-ON49258156.005D1F5A-49258156.005D4F00@notes.na.collabserv.com>
References: <OF2AAD04AE.D1E25224-ON4925814C.001B6E1D-4925814C.001CA256@notes.na.collabserv.com>
 <a9178440-aea1-c2aa-7aab-77536a972dda@oracle.com>
 <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com>
 <9a235816b1544dd587a1e6d2268e6407@sap.com>
 <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com>
 <efd1ec13120c48ecb3a977dc244d6250@sap.com>
 <OFBFC52ED9.A91AAECA-ON4925814D.0035FF61-4925814D.0036DC3B@notes.na.collabserv.com>
 <254e340e1a084a57bd77c1a99884ce1b@sap.com>
 <OF7B52711E.FAF07D7E-ON4925814E.0066EBA0-4925814E.00676717@notes.na.collabserv.com>
 <dceda7ca-e2dd-63bd-e7a2-518862ed6535@oracle.com>
 <OFFAA5395C.D74BB21D-ON4925814F.006552C5-4925814F.0065B63E@notes.na.collabserv.com>
 <af2789b9dbed4b5aaac9a092d1ac93e9@sap.com>
 <OFC2405516.267F666A-ON49258152.002DD379-49258152.002E977A@LocalDomain>
 <OF337963DE.CBBE34E9-ON49258156.005D1F5A-49258156.005D4F00@notes.na.collabserv.com>
Message-ID: <2281d88b48db4f8baaf5c82ffe016539@sap.com>

Hi Ogata,

I'll take care of backporting a fix to remove the "volatile" qualifier for both, JDK-8182743 and JDK-8184330.

Best regards
Christoph

> -----Original Message-----
> From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com]
> Sent: Freitag, 7. Juli 2017 18:59
> To: core-libs-dev <core-libs-dev at openjdk.java.net>; nio-
> dev at openjdk.java.net
> Cc: Langer, Christoph <christoph.langer at sap.com>
> Subject: RE: 8182743: Ineffective use of volatile hurts performance of
> Charset.atBugLevel()
> 
> Hi all,
> 
> Any comment on downporting a fix to JDK9u and JDK8u, which simply
> removes
> volatile?
> 
> 
> Regards,
> Ogata
> 
> Kazunori Ogata/Japan/IBM wrote on 2017/07/03 17:28:54:
> 
> > From: Kazunori Ogata/Japan/IBM
> > To: "Langer, Christoph" <christoph.langer at sap.com>
> > Cc: core-libs-dev <core-libs-dev at openjdk.java.net>, "nio-
> > dev at openjdk.java.net" <nio-dev at openjdk.java.net>
> > Date: 2017/07/03 17:28
> > Subject: RE: 8182743: Ineffective use of volatile hurts performance of
> > Charset.atBugLevel()
> >
> > Hi Christoph,
> >
> > Thank you very much for your help!
> >
> > For JDK9 updates and JDK8 updates, it is desirable if we can back port
> the
> > removal of volatile.  What should I do for it?
> >
> > Regards,
> > Ogata
> >
> > From: "Langer, Christoph" <christoph.langer at sap.com>
> > To: Kazunori Ogata <OGATAK at jp.ibm.com>, "nio-dev at openjdk.java.net"
> <nio-
> > dev at openjdk.java.net>
> > Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> > Date: 2017/07/03 17:17
> > Subject: RE: 8182743: Ineffective use of volatile hurts performance of
> > Charset.atBugLevel()
> >
> > Hi,
> >
> > I've pushed to JDK10 now:
> http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/
> > 7a2bc0a80087
> >
> > What do you think, shall we try to downport a fix to JDK9 updates and
> JDK8
> > updates, which simply removes the volatile as we can't bring this
> behavior
> > changing fix down?
> >
> > Thanks
> > Christoph
> >
> > > -----Original Message-----
> > > From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com]
> > > Sent: Freitag, 30. Juni 2017 20:31
> > > To: Se?n Coffey <sean.coffey at oracle.com>
> > > Cc: Langer, Christoph <christoph.langer at sap.com>; core-libs-dev
> <core-libs-
> > > dev at openjdk.java.net>; nio-dev at openjdk.java.net; ppc-aix-port-
> > > dev at openjdk.java.net
> > > Subject: Re: 8182743: Ineffective use of volatile hurts performance of
> > > Charset.atBugLevel()
> > >
> > > Hi Sean,
> > >
> > > Thank you for your comments.
> > >
> > > I fixed the copyright and updated webrev:
> > >
> > > http://cr.openjdk.java.net/~horii/8182743/webrev.03/
> > >
> > >
> > > > * The bug ID referenced in mail/webrev links is wrong. It should be
> > > > 8182743 ?
> > >
> > > Yes, they should be 8182743.  I fixed both.
> > >
> > >
> > > Regards,
> > > Ogata
> > >
> > >
> > > Se?n Coffey <sean.coffey at oracle.com> wrote on 2017/06/30 23:57:25:
> > >
> > > > From: Se?n Coffey <sean.coffey at oracle.com>
> > > > To: Kazunori Ogata <OGATAK at jp.ibm.com>, "Langer, Christoph"
> > > > <christoph.langer at sap.com>
> > > > Cc: "ppc-aix-port-dev at openjdk.java.net" <ppc-aix-port-
> > > > dev at openjdk.java.net>, core-libs-dev
> <core-libs-dev at openjdk.java.net>,
> > > > "nio-dev at openjdk.java.net" <nio-dev at openjdk.java.net>
> > > > Date: 2017/06/30 23:57
> > > > Subject: Re: 8179527:(8182743?) Ineffective use of volatile hurts
> > > > performance of Charset.atBugLevel()
> > > >
> > > > Ogata,
> > > >
> > > > minor comments from me.
> > > >
> > > > * The bug ID referenced in mail/webrev links is wrong. It should be
> > > > 8182743 ?
> > > > * The copyright change in Charset-X-Coder.java.template is the wrong
> > > > format. You can simply replace 2013 with 2017.
> > > >
> > > > Regards,
> > > > Sean.
> > > >
> > > > On 29/06/17 19:49, Kazunori Ogata wrote:
> > > > > Hi Christoph,
> > > > >
> > > > > I updated webrev:
> > > http://cr.openjdk.java.net/~horii/8179527/webrev.02/
> > > > >
> > > > > This one includes changes in tests.  I removed all @run and @build
> > > > > directives in the tests because those after removing "@run
> > > main/othervm
> > > > > -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" are the same as the
> > > default
> > > > > ones.  I checked the modified tests passed.
> > > > >
> > > > > I also fixed the copyright lines.
> > > > >
> > > > >
> > > > > Regards,
> > > > > Ogata
> > > > >
> > > > >
> > > > > "Langer, Christoph" <christoph.langer at sap.com> wrote on
> 2017/06/28
> > > > > 21:04:36:
> > > > >
> > > > >> From: "Langer, Christoph" <christoph.langer at sap.com>
> > > > >> To: Kazunori Ogata <OGATAK at jp.ibm.com>
> > > > >> Cc: Alan Bateman <Alan.Bateman at oracle.com>, Claes Redestad
> > > > >> <claes.redestad at oracle.com>, core-libs-dev <core-libs-
> > > > >> dev at openjdk.java.net>, "nio-dev at openjdk.java.net" <nio-
> > > > >> dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net"
> > > > > <ppc-aix-port-
> > > > >> dev at openjdk.java.net>
> > > > >> Date: 2017/06/28 21:04
> > > > >> Subject: RE: 8179527: Ineffective use of volatile hurts
> performance
> > > of
> > > > >> Charset.atBugLevel()
> > > > >>
> > > > >> Hi Ogata,
> > > > >>
> > > > >>>> remove the second run with -Dsun.nio.cs.bugLevel=1.4
> > > > >>> How can I do this?  Is it sufficient to remove the following
> line at
> > > > > the
> > > > >>> beginning of the file?: "@run main/othervm
> -Dsun.nio.cs.bugLevel=1.4
> > > > >>> EmptyCharsetName"
> > > > >> Yes, this line should be removed. Currently there are two @run
> > > > > directives
> > > > >> which cause running the testcase twice. Once in normal mode and
> once
> > > > > with
> > > > >> bugLevel set to 1.4. So, if "sun.nio.cs.bugLevel" ought to be
> removed
> > > > > then
> > > > >> the second iteration of the test is obsolete. And then one should
> > > > > probably
> > > > >> remove the whole "compat" handling in the test.
> > > > >>
> > > > >> Best regards
> > > > >> Christoph
> > > > >>
> > > > >
> > > >
> > >
> >
> 


From OGATAK at jp.ibm.com  Thu Jul 13 10:49:58 2017
From: OGATAK at jp.ibm.com (Kazunori Ogata)
Date: Thu, 13 Jul 2017 19:49:58 +0900
Subject: 8182743: Ineffective use of volatile hurts performance of
 Charset.atBugLevel()
In-Reply-To: <2281d88b48db4f8baaf5c82ffe016539@sap.com>
References: <OF2AAD04AE.D1E25224-ON4925814C.001B6E1D-4925814C.001CA256@notes.na.collabserv.com>
 <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com>
 <9a235816b1544dd587a1e6d2268e6407@sap.com>
 <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com>
 <efd1ec13120c48ecb3a977dc244d6250@sap.com>
 <OFBFC52ED9.A91AAECA-ON4925814D.0035FF61-4925814D.0036DC3B@notes.na.collabserv.com>
 <254e340e1a084a57bd77c1a99884ce1b@sap.com>
 <OF7B52711E.FAF07D7E-ON4925814E.0066EBA0-4925814E.00676717@notes.na.collabserv.com>
 <dceda7ca-e2dd-63bd-e7a2-518862ed6535@oracle.com>
 <OFFAA5395C.D74BB21D-ON4925814F.006552C5-4925814F.0065B63E@notes.na.collabserv.com>
 <af2789b9dbed4b5aaac9a092d1ac93e9@sap.com>
 <OFC2405516.267F666A-ON49258152.002DD379-49258152.002E977A@LocalDomain>
 <OF337963DE.CBBE34 <2281d88b48db4f8baaf5c82ffe016539@sap.com>
Message-ID: <OF8D015BA6.B116AEAA-ON4925815C.003B7994-4925815C.003B8FA6@notes.na.collabserv.com>

Hi Christoph,

Thank you for your help!


Regards,
Ogata

"Langer, Christoph" <christoph.langer at sap.com> wrote on 2017/07/13 
19:32:32:

> From: "Langer, Christoph" <christoph.langer at sap.com>
> To: Kazunori Ogata <OGATAK at jp.ibm.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>, "nio-
> dev at openjdk.java.net" <nio-dev at openjdk.java.net>
> Date: 2017/07/13 19:32
> Subject: RE: 8182743: Ineffective use of volatile hurts performance of 
> Charset.atBugLevel()
> 
> Hi Ogata,
> 
> I'll take care of backporting a fix to remove the "volatile" qualifier 
for
> both, JDK-8182743 and JDK-8184330.
> 
> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com]
> > Sent: Freitag, 7. Juli 2017 18:59
> > To: core-libs-dev <core-libs-dev at openjdk.java.net>; nio-
> > dev at openjdk.java.net
> > Cc: Langer, Christoph <christoph.langer at sap.com>
> > Subject: RE: 8182743: Ineffective use of volatile hurts performance of
> > Charset.atBugLevel()
> > 
> > Hi all,
> > 
> > Any comment on downporting a fix to JDK9u and JDK8u, which simply
> > removes
> > volatile?
> > 
> > 
> > Regards,
> > Ogata
> > 
> > Kazunori Ogata/Japan/IBM wrote on 2017/07/03 17:28:54:
> > 
> > > From: Kazunori Ogata/Japan/IBM
> > > To: "Langer, Christoph" <christoph.langer at sap.com>
> > > Cc: core-libs-dev <core-libs-dev at openjdk.java.net>, "nio-
> > > dev at openjdk.java.net" <nio-dev at openjdk.java.net>
> > > Date: 2017/07/03 17:28
> > > Subject: RE: 8182743: Ineffective use of volatile hurts performance 
of
> > > Charset.atBugLevel()
> > >
> > > Hi Christoph,
> > >
> > > Thank you very much for your help!
> > >
> > > For JDK9 updates and JDK8 updates, it is desirable if we can back 
port
> > the
> > > removal of volatile.  What should I do for it?
> > >
> > > Regards,
> > > Ogata
> > >
> > > From: "Langer, Christoph" <christoph.langer at sap.com>
> > > To: Kazunori Ogata <OGATAK at jp.ibm.com>, "nio-dev at openjdk.java.net"
> > <nio-
> > > dev at openjdk.java.net>
> > > Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> > > Date: 2017/07/03 17:17
> > > Subject: RE: 8182743: Ineffective use of volatile hurts performance 
of
> > > Charset.atBugLevel()
> > >
> > > Hi,
> > >
> > > I've pushed to JDK10 now:
> > http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/
> > > 7a2bc0a80087
> > >
> > > What do you think, shall we try to downport a fix to JDK9 updates 
and
> > JDK8
> > > updates, which simply removes the volatile as we can't bring this
> > behavior
> > > changing fix down?
> > >
> > > Thanks
> > > Christoph
> > >
> > > > -----Original Message-----
> > > > From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com]
> > > > Sent: Freitag, 30. Juni 2017 20:31
> > > > To: Se?n Coffey <sean.coffey at oracle.com>
> > > > Cc: Langer, Christoph <christoph.langer at sap.com>; core-libs-dev
> > <core-libs-
> > > > dev at openjdk.java.net>; nio-dev at openjdk.java.net; ppc-aix-port-
> > > > dev at openjdk.java.net
> > > > Subject: Re: 8182743: Ineffective use of volatile hurts 
performance of
> > > > Charset.atBugLevel()
> > > >
> > > > Hi Sean,
> > > >
> > > > Thank you for your comments.
> > > >
> > > > I fixed the copyright and updated webrev:
> > > >
> > > > http://cr.openjdk.java.net/~horii/8182743/webrev.03/
> > > >
> > > >
> > > > > * The bug ID referenced in mail/webrev links is wrong. It should 
be
> > > > > 8182743 ?
> > > >
> > > > Yes, they should be 8182743.  I fixed both.
> > > >
> > > >
> > > > Regards,
> > > > Ogata
> > > >
> > > >
> > > > Se?n Coffey <sean.coffey at oracle.com> wrote on 2017/06/30 23:57:25:
> > > >
> > > > > From: Se?n Coffey <sean.coffey at oracle.com>
> > > > > To: Kazunori Ogata <OGATAK at jp.ibm.com>, "Langer, Christoph"
> > > > > <christoph.langer at sap.com>
> > > > > Cc: "ppc-aix-port-dev at openjdk.java.net" <ppc-aix-port-
> > > > > dev at openjdk.java.net>, core-libs-dev
> > <core-libs-dev at openjdk.java.net>,
> > > > > "nio-dev at openjdk.java.net" <nio-dev at openjdk.java.net>
> > > > > Date: 2017/06/30 23:57
> > > > > Subject: Re: 8179527:(8182743?) Ineffective use of volatile 
hurts
> > > > > performance of Charset.atBugLevel()
> > > > >
> > > > > Ogata,
> > > > >
> > > > > minor comments from me.
> > > > >
> > > > > * The bug ID referenced in mail/webrev links is wrong. It should 
be
> > > > > 8182743 ?
> > > > > * The copyright change in Charset-X-Coder.java.template is the 
wrong
> > > > > format. You can simply replace 2013 with 2017.
> > > > >
> > > > > Regards,
> > > > > Sean.
> > > > >
> > > > > On 29/06/17 19:49, Kazunori Ogata wrote:
> > > > > > Hi Christoph,
> > > > > >
> > > > > > I updated webrev:
> > > > http://cr.openjdk.java.net/~horii/8179527/webrev.02/
> > > > > >
> > > > > > This one includes changes in tests.  I removed all @run and 
@build
> > > > > > directives in the tests because those after removing "@run
> > > > main/othervm
> > > > > > -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" are the same as 
the
> > > > default
> > > > > > ones.  I checked the modified tests passed.
> > > > > >
> > > > > > I also fixed the copyright lines.
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Ogata
> > > > > >
> > > > > >
> > > > > > "Langer, Christoph" <christoph.langer at sap.com> wrote on
> > 2017/06/28
> > > > > > 21:04:36:
> > > > > >
> > > > > >> From: "Langer, Christoph" <christoph.langer at sap.com>
> > > > > >> To: Kazunori Ogata <OGATAK at jp.ibm.com>
> > > > > >> Cc: Alan Bateman <Alan.Bateman at oracle.com>, Claes Redestad
> > > > > >> <claes.redestad at oracle.com>, core-libs-dev <core-libs-
> > > > > >> dev at openjdk.java.net>, "nio-dev at openjdk.java.net" <nio-
> > > > > >> dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net"
> > > > > > <ppc-aix-port-
> > > > > >> dev at openjdk.java.net>
> > > > > >> Date: 2017/06/28 21:04
> > > > > >> Subject: RE: 8179527: Ineffective use of volatile hurts
> > performance
> > > > of
> > > > > >> Charset.atBugLevel()
> > > > > >>
> > > > > >> Hi Ogata,
> > > > > >>
> > > > > >>>> remove the second run with -Dsun.nio.cs.bugLevel=1.4
> > > > > >>> How can I do this?  Is it sufficient to remove the following
> > line at
> > > > > > the
> > > > > >>> beginning of the file?: "@run main/othervm
> > -Dsun.nio.cs.bugLevel=1.4
> > > > > >>> EmptyCharsetName"
> > > > > >> Yes, this line should be removed. Currently there are two 
@run
> > > > > > directives
> > > > > >> which cause running the testcase twice. Once in normal mode 
and
> > once
> > > > > > with
> > > > > >> bugLevel set to 1.4. So, if "sun.nio.cs.bugLevel" ought to be
> > removed
> > > > > > then
> > > > > >> the second iteration of the test is obsolete. And then one 
should
> > > > > > probably
> > > > > >> remove the whole "compat" handling in the test.
> > > > > >>
> > > > > >> Best regards
> > > > > >> Christoph
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> > 
> 



From Alan.Bateman at oracle.com  Thu Jul 13 11:14:09 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 13 Jul 2017 12:14:09 +0100
Subject: RFR(S): 8184330: Remove sun.nio.ch.Util.atBugLevel() either
 completely or at least get rid of volatile field bugLevel
In-Reply-To: <36fe20638f7a4dfd80577d20570dea81@sap.com>
References: <36fe20638f7a4dfd80577d20570dea81@sap.com>
Message-ID: <c2a8ddd1-9f46-9217-1594-3224b851d60e@oracle.com>



On 13/07/2017 11:29, Langer, Christoph wrote:
>
> Hi,
>
> after getting in the fix for JDK-8182743 [1] that removes 
> ?sun.nio.cs.bugLevel?, I?m taking on Claes? suggestion [2]  to also 
> tackle ?sun.nio.ch.bugLevel?. The bugLevel check is done to enable 
> some JDK 1.4 compatible mode which I hope is safe to be dropped with 
> JDK10. Unfortunately I didn?t find the bug that introduced 
> ?sun.nio.cs.bugLevel?, maybe someone can shed some more light on its 
> history. I?m hoping that it?s ok to remove this one as well. If there 
> are no objections and I get it reviewed then I?ll open a CSR request.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8184330 
> <https://bugs.openjdk.java.net/browse/JDK-8184330>
>
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8184330.0/ 
> <http://cr.openjdk.java.net/%7Eclanger/webrevs/8184330.0/>
>
>
Looks okay except you've removed a blank line from SelectorImpl. If you 
can fix that then it looks okay.

-Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170713/3badc74d/attachment-0001.html>

From christoph.langer at sap.com  Thu Jul 13 11:54:23 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 13 Jul 2017 11:54:23 +0000
Subject: RFR(S): 8184330: Remove sun.nio.ch.Util.atBugLevel() either
 completely or at least get rid of volatile field bugLevel
In-Reply-To: <c2a8ddd1-9f46-9217-1594-3224b851d60e@oracle.com>
References: <36fe20638f7a4dfd80577d20570dea81@sap.com>
 <c2a8ddd1-9f46-9217-1594-3224b851d60e@oracle.com>
Message-ID: <9f8867ae6c574da7ae2095054b8fc37f@sap.com>

Hi Alan,

thanks. I have updated the webrev in place.

As for documentation/bugids: I found that one: http://www.oracle.com/technetwork/java/javase/compatibility-417013.html. However, the text in there seems not to be quite correct (any more) as it talks about bugLevel could be set to "1.4", "1.5" or "1.6" - which you can do but obviously has no effect. And the referenced bug (https://bugs.openjdk.java.net/browse/JDK-6621689) does not talk about "sun.nio.ch.bugLevel". Are you aware of any more information that I can use for the CSR?

Best regards
Christoph


From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
Sent: Donnerstag, 13. Juli 2017 13:14
To: Langer, Christoph <christoph.langer at sap.com>; nio-dev at openjdk.java.net
Subject: Re: RFR(S): 8184330: Remove sun.nio.ch.Util.atBugLevel() either completely or at least get rid of volatile field bugLevel


On 13/07/2017 11:29, Langer, Christoph wrote:
Hi,

after getting in the fix for JDK-8182743 [1] that removes "sun.nio.cs.bugLevel", I'm taking on Claes' suggestion [2]  to also tackle "sun.nio.ch.bugLevel". The bugLevel check is done to enable some JDK 1.4 compatible mode which I hope is safe to be dropped with JDK10. Unfortunately I didn't find the bug that introduced "sun.nio.cs.bugLevel", maybe someone can shed some more light on its history. I'm hoping that it's ok to remove this one as well. If there are no objections and I get it reviewed then I'll open a CSR request.

Bug: https://bugs.openjdk.java.net/browse/JDK-8184330
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8184330.0/<http://cr.openjdk.java.net/%7Eclanger/webrevs/8184330.0/>

Looks okay except you've removed a blank line from SelectorImpl. If you can fix that then it looks okay.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170713/cedb3276/attachment.html>

From Alan.Bateman at oracle.com  Sun Jul 16 09:44:13 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 16 Jul 2017 10:44:13 +0100
Subject: RFR(S): 8184330: Remove sun.nio.ch.Util.atBugLevel() either
 completely or at least get rid of volatile field bugLevel
In-Reply-To: <9f8867ae6c574da7ae2095054b8fc37f@sap.com>
References: <36fe20638f7a4dfd80577d20570dea81@sap.com>
 <c2a8ddd1-9f46-9217-1594-3224b851d60e@oracle.com>
 <9f8867ae6c574da7ae2095054b8fc37f@sap.com>
Message-ID: <c9272bf2-99ea-148e-fdb4-4ad3ea52698c@oracle.com>



On 13/07/2017 12:54, Langer, Christoph wrote:
>
> Hi Alan,
>
> thanks. I have updated the webrev in place.
>
The updated webrev looks good.
>
> As for documentation/bugids: I found that one: 
> http://www.oracle.com/technetwork/java/javase/compatibility-417013.html. 
> However, the text in there seems not to be quite correct (any more) as 
> it talks about bugLevel could be set to ?1.4?, ?1.5? or ?1.6? ? which 
> you can do but obviously has no effect. And the referenced bug 
> (https://bugs.openjdk.java.net/browse/JDK-6621689) does not talk about 
> ?sun.nio.ch.bugLevel?. Are you aware of any more information that I 
> can use for the CSR?
>
>
The first part of this JDK 7 release note looks right but I don't know 
why it documents that the bugLevel property that can configured to 
restore old behavior. I suspect (but not certain) that it has been mixed 
up with another change.



-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170716/9e649b23/attachment.html>

From christoph.langer at sap.com  Mon Jul 17 12:58:31 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 17 Jul 2017 12:58:31 +0000
Subject: RFR(S): 8184330: Remove sun.nio.ch.Util.atBugLevel() either
 completely or at least get rid of volatile field bugLevel
In-Reply-To: <c9272bf2-99ea-148e-fdb4-4ad3ea52698c@oracle.com>
References: <36fe20638f7a4dfd80577d20570dea81@sap.com>
 <c2a8ddd1-9f46-9217-1594-3224b851d60e@oracle.com>
 <9f8867ae6c574da7ae2095054b8fc37f@sap.com>
 <c9272bf2-99ea-148e-fdb4-4ad3ea52698c@oracle.com>
Message-ID: <e5a3de7abf524461859badf7808f43d0@sap.com>

Thanks Alan!

Could you please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8184742 ?

Best regards
Christoph

From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
Sent: Sonntag, 16. Juli 2017 11:44
To: Langer, Christoph <christoph.langer at sap.com>
Cc: nio-dev at openjdk.java.net
Subject: Re: RFR(S): 8184330: Remove sun.nio.ch.Util.atBugLevel() either completely or at least get rid of volatile field bugLevel


On 13/07/2017 12:54, Langer, Christoph wrote:
Hi Alan,

thanks. I have updated the webrev in place.
The updated webrev looks good.

As for documentation/bugids: I found that one: http://www.oracle.com/technetwork/java/javase/compatibility-417013.html. However, the text in there seems not to be quite correct (any more) as it talks about bugLevel could be set to "1.4", "1.5" or "1.6" - which you can do but obviously has no effect. And the referenced bug (https://bugs.openjdk.java.net/browse/JDK-6621689) does not talk about "sun.nio.ch.bugLevel". Are you aware of any more information that I can use for the CSR?

The first part of this JDK 7 release note looks right but I don't know why it documents that the bugLevel property that can configured to restore old behavior. I suspect (but not certain) that it has been mixed up with another change.



-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170717/a7dcf8fe/attachment.html>

From brian.burkhalter at oracle.com  Mon Jul 17 19:49:42 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 17 Jul 2017 12:49:42 -0700
Subject: JDK 10 RFR of test-only bug 8183320,
 et. al.: Better cleanup of temp files created by [N]IO tests
Message-ID: <95464FBD-8338-4823-8CAC-0B73A0BFB1F0@oracle.com>

Please review at your convenience this patch for [1, 2, 3, 4]:

http://cr.openjdk.java.net/~bpb/8183320/webrev.00/

Note that without the existence check at line 60, the SetDefaultProvider test fails with a FileAlreadyExistsException.

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8183320
[2] https://bugs.openjdk.java.net/browse/JDK-8183321
[3] https://bugs.openjdk.java.net/browse/JDK-8183343
[4] https://bugs.openjdk.java.net/browse/JDK-8183344

From chris.hegarty at oracle.com  Tue Jul 18 10:40:14 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 18 Jul 2017 11:40:14 +0100
Subject: JDK 10 RFR of test-only bug 8183320,
 et. al.: Better cleanup of temp files created by [N]IO tests
In-Reply-To: <95464FBD-8338-4823-8CAC-0B73A0BFB1F0@oracle.com>
References: <95464FBD-8338-4823-8CAC-0B73A0BFB1F0@oracle.com>
Message-ID: <11149BE1-5781-438B-89DF-03409FA851BA@oracle.com>


> On 17 Jul 2017, at 20:49, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> Please review at your convenience this patch for [1, 2, 3, 4]:
> 
> http://cr.openjdk.java.net/~bpb/8183320/webrev.00/

These mainly look fine.

On test/java/io/File/createTempFile/SpecialTempFile.java, your changes
seem to change what is being tested. Is this intentional?

-Chris.

From Alan.Bateman at oracle.com  Tue Jul 18 11:09:59 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 18 Jul 2017 12:09:59 +0100
Subject: JDK 10 RFR of test-only bug 8183320, et. al.: Better cleanup of
 temp files created by [N]IO tests
In-Reply-To: <95464FBD-8338-4823-8CAC-0B73A0BFB1F0@oracle.com>
References: <95464FBD-8338-4823-8CAC-0B73A0BFB1F0@oracle.com>
Message-ID: <9e636b00-ea4f-3998-d276-b5337fc00234@oracle.com>

On 17/07/2017 20:49, Brian Burkhalter wrote:
> Please review at your convenience this patch for [1, 2, 3, 4]:
>
> http://cr.openjdk.java.net/~bpb/8183320/webrev.00/
>
> Note that without the existence check at line 60, the SetDefaultProvider test fails with a FileAlreadyExistsException.
>
>
In SetDefaultProvider then it's important that the tests get a unique 
temp directory, otherwise will get interference between the 
testExplodedWithXXXX tests. This should do it:

   Path here = Paths.get("");
   Patch patchdir = Files.createTempDirectory(here, "patch");

-Alan

From brian.burkhalter at oracle.com  Tue Jul 18 18:25:24 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 18 Jul 2017 11:25:24 -0700
Subject: JDK 10 RFR of 8184807: (ch) Clean up handling of some Windows
 function return values in libnio
Message-ID: <6BF38276-3656-4332-ADEC-F71AA77C11F8@oracle.com>

Please review at your convenience:

https://bugs.openjdk.java.net/browse/JDK-8184807
http://cr.openjdk.java.net/~bpb/8184807/webrev.00/

The return values of some Windows functions are incorrectly tested or not tested at all. This change would clean these up.

Thanks,

Brian

From Alan.Bateman at oracle.com  Tue Jul 18 19:14:46 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 18 Jul 2017 20:14:46 +0100
Subject: JDK 10 RFR of 8184807: (ch) Clean up handling of some Windows
 function return values in libnio
In-Reply-To: <6BF38276-3656-4332-ADEC-F71AA77C11F8@oracle.com>
References: <6BF38276-3656-4332-ADEC-F71AA77C11F8@oracle.com>
Message-ID: <39cf7ed9-9a54-3cbf-4da2-55db6fa11872@oracle.com>



On 18/07/2017 19:25, Brian Burkhalter wrote:
> Please review at your convenience:
>
> https://bugs.openjdk.java.net/browse/JDK-8184807
> http://cr.openjdk.java.net/~bpb/8184807/webrev.00/
>
> The return values of some Windows functions are incorrectly tested or not tested at all. This change would clean these up.
>
>
Looks good.

From brian.burkhalter at oracle.com  Wed Jul 19 00:58:27 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 18 Jul 2017 17:58:27 -0700
Subject: JDK 10 RFR of test-only bug 8183320,
 et. al.: Better cleanup of temp files created by [N]IO tests
In-Reply-To: <11149BE1-5781-438B-89DF-03409FA851BA@oracle.com>
References: <95464FBD-8338-4823-8CAC-0B73A0BFB1F0@oracle.com>
 <11149BE1-5781-438B-89DF-03409FA851BA@oracle.com>
Message-ID: <4ACCD371-ABDB-4C29-839A-5B2FA1440FC2@oracle.com>

On Jul 18, 2017, at 3:40 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:

>> On 17 Jul 2017, at 20:49, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
>> 
>> Please review at your convenience this patch for [1, 2, 3, 4]:
>> 
>> http://cr.openjdk.java.net/~bpb/8183320/webrev.00/
> 
> These mainly look fine.
> 
> On test/java/io/File/createTempFile/SpecialTempFile.java, your changes
> seem to change what is being tested. Is this intentional?

Actually looking back over it, my changes in this test were a no-op: they merely changed how an unused variable was initialized. Hopefully the updated version [1] is correct.

On Jul 18, 2017, at 4:09 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 17/07/2017 20:49, Brian Burkhalter wrote:
>> Please review at your convenience this patch for [1, 2, 3, 4]:
>> 
>> http://cr.openjdk.java.net/~bpb/8183320/webrev.00/
>> 
>> Note that without the existence check at line 60, the SetDefaultProvider test fails with a FileAlreadyExistsException.
>> 
> In SetDefaultProvider then it's important that the tests get a unique temp directory, otherwise will get interference between the testExplodedWithXXXX tests. This should do it:
> 
>  Path here = Paths.get("");
>  Patch patchdir = Files.createTempDirectory(here, "patch");


I changed it to something slightly different [1] from the above suggestion:
    private static Path createTempDirectory(String prefix) throws IOException {
        Path testDir = Paths.get(System.getProperty("test.dir", "."));
        return Files.createTempDirectory(testDir, prefix);
    }
In version .01 of the patch, only SpecialTempFile and SetDefaultProvider are changed with respect to version .00.
Thanks,

Brian

[1] http://cr.openjdk.java.net/~bpb/8183320/webrev.01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170718/32f556f8/attachment.html>

From vyom.tewari at oracle.com  Wed Jul 19 04:05:05 2017
From: vyom.tewari at oracle.com (vyom tewari)
Date: Wed, 19 Jul 2017 09:35:05 +0530
Subject: JDK 10 RFR of 8184807: (ch) Clean up handling of some Windows
 function return values in libnio
In-Reply-To: <6BF38276-3656-4332-ADEC-F71AA77C11F8@oracle.com>
References: <6BF38276-3656-4332-ADEC-F71AA77C11F8@oracle.com>
Message-ID: <d9f545eb-a7ae-8ff3-3117-261b72cdb816@oracle.com>

Hi Brian,

You can remove the unnecessary local variable "BOOL result" from 
WindowsAsynchronousFileChannelImpl.c & FileChannelImpl.c.

Thanks,

Vyom


On Tuesday 18 July 2017 11:55 PM, Brian Burkhalter wrote:
> Please review at your convenience:
>
> https://bugs.openjdk.java.net/browse/JDK-8184807
> http://cr.openjdk.java.net/~bpb/8184807/webrev.00/
>
> The return values of some Windows functions are incorrectly tested or not tested at all. This change would clean these up.
>
> Thanks,
>
> Brian


From Alan.Bateman at oracle.com  Wed Jul 19 13:57:40 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 19 Jul 2017 14:57:40 +0100
Subject: JDK 10 RFR of test-only bug 8183320, et. al.: Better cleanup of
 temp files created by [N]IO tests
In-Reply-To: <4ACCD371-ABDB-4C29-839A-5B2FA1440FC2@oracle.com>
References: <95464FBD-8338-4823-8CAC-0B73A0BFB1F0@oracle.com>
 <11149BE1-5781-438B-89DF-03409FA851BA@oracle.com>
 <4ACCD371-ABDB-4C29-839A-5B2FA1440FC2@oracle.com>
Message-ID: <98c6e138-6d7a-b234-96e9-3b9c18869281@oracle.com>



On 19/07/2017 01:58, Brian Burkhalter wrote:
> In version .01 of the patch, only SpecialTempFile and 
> SetDefaultProvider are changed with respect to version .00.
>
The updated version looks good to me.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170719/071af970/attachment.html>

From brian.burkhalter at oracle.com  Wed Jul 19 18:43:49 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 19 Jul 2017 11:43:49 -0700
Subject: JDK 10 RFR of 8184807: (ch) Clean up handling of some Windows
 function return values in libnio
In-Reply-To: <d9f545eb-a7ae-8ff3-3117-261b72cdb816@oracle.com>
References: <6BF38276-3656-4332-ADEC-F71AA77C11F8@oracle.com>
 <d9f545eb-a7ae-8ff3-3117-261b72cdb816@oracle.com>
Message-ID: <504DF693-CFD0-496D-AFBC-DD6B24F00D9F@oracle.com>

Hi Vyom,

It?s too late for this patch, which had already been pushed before your message was sent, so perhaps in the future. However I am probably missing something, but I do not see any such unused variables in [1] or [2]. Would you please provide the specific line numbers in question?

Thanks,

Brian

[1] http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/4fb5f3049c2c/src/java.base/windows/native/libnio/ch/FileChannelImpl.c
[2] http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/4fb5f3049c2c/src/java.base/windows/native/libnio/ch/WindowsAsynchronousFileChannelImpl.c

On Jul 18, 2017, at 9:05 PM, vyom tewari <vyom.tewari at oracle.com> wrote:

> You can remove the unnecessary local variable "BOOL result" from WindowsAsynchronousFileChannelImpl.c & FileChannelImpl.c.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170719/0af6a243/attachment.html>

From brian.burkhalter at oracle.com  Mon Jul 24 22:54:55 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 24 Jul 2017 15:54:55 -0700
Subject: JDK 10 RFR of 8184157: (ch) AsynchronousFileChannel hangs with
 internal error when reading locked file
Message-ID: <B5718195-0CF8-4FAC-8985-72464164127B@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8184157
http://cr.openjdk.java.net/~bpb/8184157/webrev.00/

This problem is caused by a race condition wherein the PendingFuture of a lock operation in the PendingIoCache is replaced by that of a read operation, with both using the same key, before the completion status of the lock operation is dequeued by the event handler thread of Iocp. When the lock completion status is dequeued, the event handler looks up its corresponding PendingFuture but retrieves that of the read operation instead. This causes the completed() callback of the read task to be invoked with the NumberOfBytes transferred for the lock operation which is a garbage value. This results in an attempt to set the read ByteBuffer position to a value outside its permitted range.

The proposed solution is to introduce an invalidate() method on the PendingIoCache which removes the entry corresponding to the OVERLAPPED pointer from the map of overlapped-to-PendingFuture entries and places the OVERLAPPED pointer value in a Set where it remains until remove() is called. This ensures that the OVERLAPPED pointer map key will not be used for a PendingFuture to which it does not correspond. The pointer values of invalidated PendingFutures are removed from the Set when remove() is called in the Iocp event handler after the corresponding completion status is dequeued. All existing regression tests pass with this patch applied.

Thanks,

Brian

From brian.burkhalter at oracle.com  Wed Jul 26 17:52:24 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 26 Jul 2017 10:52:24 -0700
Subject: JDK 10 RFR of 8185092: Data race in FilterOutputStream.close
Message-ID: <DBCE209F-FC6F-426A-818E-A13B28CE7207@oracle.com>

Issue: https://bugs.openjdk.java.net/browse/JDK-8185092
Patch: see diff below

Change the type of the instance variable ?closed? from boolean to AtomicBoolean. A similar approach is used in RandomAccessFile [1] and AbstractSelector [2]. An alternative would be a volatile boolean and a synchronization block [3]. The test is updated only to increment the copyright year and add the bug ID.

Thanks,

Brian

[1] http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/26e2e601515e/src/java.base/share/classes/java/io/RandomAccessFile.java#l638
[2] http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/26e2e601515e/src/java.base/share/classes/java/nio/channels/spi/AbstractSelector.java#l107
[3] http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/d93f2fd542b7/src/java.base/share/classes/java/io/FileOutputStream.java#l348

--- a/src/java.base/share/classes/java/io/FilterOutputStream.java
+++ b/src/java.base/share/classes/java/io/FilterOutputStream.java
@@ -25,6 +25,8 @@
 
 package java.io;
 
+import java.util.concurrent.atomic.AtomicBoolean;
+
 /**
  * This class is the superclass of all classes that filter output
  * streams. These streams sit on top of an already existing output
@@ -50,7 +52,7 @@
     /**
      * Whether the stream is closed; implicitly initialized to false.
      */
-    private boolean closed;
+    private AtomicBoolean closed = new AtomicBoolean();
 
     /**
      * Creates an output stream filter built on top of the specified
@@ -162,10 +164,9 @@
      */
     @Override
     public void close() throws IOException {
-        if (closed) {
+        if (closed.getAndSet(true)) {
             return;
         }
-        closed = true;
 
         Throwable flushException = null;
         try {

+++ b/test/java/io/etc/FailingFlushAndClose.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2011, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2011, 2017, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -25,7 +25,7 @@
 
 /**
  * @test
- * @bug 7015589 8054565
+ * @bug 7015589 8054565 8185092
  * @summary Test that buffering streams are considered closed even when the
  *    close or flush from the underlying stream fails.
  */

From martinrb at google.com  Wed Jul 26 18:25:53 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 26 Jul 2017 11:25:53 -0700
Subject: JDK 10 RFR of 8185092: Data race in FilterOutputStream.close
In-Reply-To: <DBCE209F-FC6F-426A-818E-A13B28CE7207@oracle.com>
References: <DBCE209F-FC6F-426A-818E-A13B28CE7207@oracle.com>
Message-ID: <CA+kOe0-NR4TxKp4-QukFPjom6QzjSNqUshjEA+qfz-dhf2-fdw@mail.gmail.com>

Making close exactly-once as you have done is probably the right strategy.

Probably most of java.io was designed to be "mostly thread-safe" as was
common culture back in the last millennium.  There were no "synchronized"
in FilterOutputStream probably because previously there was no need!

For jdk10 VarHandles are probably generally preferred to j.u.c.atomic
classes.

The lack of thread safety specs (and general java.io love) remains a long
term big problem.

It's weird to add @bug to a test without changing the test itself.  Is the
test really testing this fix?

On Wed, Jul 26, 2017 at 10:52 AM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> Issue: https://bugs.openjdk.java.net/browse/JDK-8185092
> Patch: see diff below
>
> Change the type of the instance variable ?closed? from boolean to
> AtomicBoolean. A similar approach is used in RandomAccessFile [1] and
> AbstractSelector [2]. An alternative would be a volatile boolean and a
> synchronization block [3]. The test is updated only to increment the
> copyright year and add the bug ID.
>
> Thanks,
>
> Brian
>
> [1] http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/
> 26e2e601515e/src/java.base/share/classes/java/io/
> RandomAccessFile.java#l638
> [2] http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/
> 26e2e601515e/src/java.base/share/classes/java/nio/
> channels/spi/AbstractSelector.java#l107
> [3] http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/
> d93f2fd542b7/src/java.base/share/classes/java/io/
> FileOutputStream.java#l348
>
> --- a/src/java.base/share/classes/java/io/FilterOutputStream.java
> +++ b/src/java.base/share/classes/java/io/FilterOutputStream.java
> @@ -25,6 +25,8 @@
>
>  package java.io;
>
> +import java.util.concurrent.atomic.AtomicBoolean;
> +
>  /**
>   * This class is the superclass of all classes that filter output
>   * streams. These streams sit on top of an already existing output
> @@ -50,7 +52,7 @@
>      /**
>       * Whether the stream is closed; implicitly initialized to false.
>       */
> -    private boolean closed;
> +    private AtomicBoolean closed = new AtomicBoolean();
>
>      /**
>       * Creates an output stream filter built on top of the specified
> @@ -162,10 +164,9 @@
>       */
>      @Override
>      public void close() throws IOException {
> -        if (closed) {
> +        if (closed.getAndSet(true)) {
>              return;
>          }
> -        closed = true;
>
>          Throwable flushException = null;
>          try {
>
> +++ b/test/java/io/etc/FailingFlushAndClose.java
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2011, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2011, 2017, Oracle and/or its affiliates. All rights
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -25,7 +25,7 @@
>
>  /**
>   * @test
> - * @bug 7015589 8054565
> + * @bug 7015589 8054565 8185092
>   * @summary Test that buffering streams are considered closed even when
> the
>   *    close or flush from the underlying stream fails.
>   */
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170726/9c29061d/attachment.html>

From brian.burkhalter at oracle.com  Wed Jul 26 18:33:02 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 26 Jul 2017 11:33:02 -0700
Subject: JDK 10 RFR of 8185092: Data race in FilterOutputStream.close
In-Reply-To: <CA+kOe0-NR4TxKp4-QukFPjom6QzjSNqUshjEA+qfz-dhf2-fdw@mail.gmail.com>
References: <DBCE209F-FC6F-426A-818E-A13B28CE7207@oracle.com>
 <CA+kOe0-NR4TxKp4-QukFPjom6QzjSNqUshjEA+qfz-dhf2-fdw@mail.gmail.com>
Message-ID: <FF403B49-98C5-4D71-A8D1-1F8CE537FD67@oracle.com>

On Jul 26, 2017, at 11:25 AM, Martin Buchholz <martinrb at google.com> wrote:

> Making close exactly-once as you have done is probably the right strategy.
> 
> Probably most of java.io was designed to be "mostly thread-safe" as was common culture back in the last millennium.  There were no "synchronized" in FilterOutputStream probably because previously there was no need!
> 
> For jdk10 VarHandles are probably generally preferred to j.u.c.atomic classes.

A blanket change from atomics could be a separate issue.

> The lack of thread safety specs (and general java.io love) remains a long term big problem.

I noticed your issue comment; this should be filed as another issue, I suppose.

> It's weird to add @bug to a test without changing the test itself.  Is the test really testing this fix?

Yes, it?s weird. It?s not really testing the fix. I was thinking of this change as correcting the patch which fixed the issue linked to this issue which uses the same test. I would actually prefer not to modify the test and instead add the label ?noreg-cleanup? as this change seems to be pretty clear.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170726/9f80c992/attachment.html>

From martinrb at google.com  Wed Jul 26 18:39:11 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 26 Jul 2017 11:39:11 -0700
Subject: JDK 10 RFR of 8185092: Data race in FilterOutputStream.close
In-Reply-To: <FF403B49-98C5-4D71-A8D1-1F8CE537FD67@oracle.com>
References: <DBCE209F-FC6F-426A-818E-A13B28CE7207@oracle.com>
 <CA+kOe0-NR4TxKp4-QukFPjom6QzjSNqUshjEA+qfz-dhf2-fdw@mail.gmail.com>
 <FF403B49-98C5-4D71-A8D1-1F8CE537FD67@oracle.com>
Message-ID: <CA+kOe0-PsvxUiuxYdifgq8kA4nq0KK8ewCZgO9Fpmgx9J6JHkw@mail.gmail.com>

Looks good to me.

I again forgot that VarHandles are still only whitelisted for
java.util.concurrent.

I would label this noreg-hard .

On Wed, Jul 26, 2017 at 11:33 AM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> On Jul 26, 2017, at 11:25 AM, Martin Buchholz <martinrb at google.com> wrote:
>
> Making close exactly-once as you have done is probably the right strategy.
>
> Probably most of java.io was designed to be "mostly thread-safe" as was
> common culture back in the last millennium.  There were no "synchronized"
> in FilterOutputStream probably because previously there was no need!
>
> For jdk10 VarHandles are probably generally preferred to j.u.c.atomic
> classes.
>
>
> A blanket change from atomics could be a separate issue.
>
> The lack of thread safety specs (and general java.io love) remains a long
> term big problem.
>
>
> I noticed your issue comment; this should be filed as another issue, I
> suppose.
>
> It's weird to add @bug to a test without changing the test itself.  Is the
> test really testing this fix?
>
>
> Yes, it?s weird. It?s not really testing the fix. I was thinking of this
> change as correcting the patch which fixed the issue linked to this issue
> which uses the same test. I would actually prefer not to modify the test
> and instead add the label ?noreg-cleanup? as this change seems to be pretty
> clear.
>
> Thanks,
>
> Brian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170726/22aad809/attachment-0001.html>

From brian.burkhalter at oracle.com  Wed Jul 26 18:41:24 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 26 Jul 2017 11:41:24 -0700
Subject: JDK 10 RFR of 8185092: Data race in FilterOutputStream.close
In-Reply-To: <CA+kOe0-PsvxUiuxYdifgq8kA4nq0KK8ewCZgO9Fpmgx9J6JHkw@mail.gmail.com>
References: <DBCE209F-FC6F-426A-818E-A13B28CE7207@oracle.com>
 <CA+kOe0-NR4TxKp4-QukFPjom6QzjSNqUshjEA+qfz-dhf2-fdw@mail.gmail.com>
 <FF403B49-98C5-4D71-A8D1-1F8CE537FD67@oracle.com>
 <CA+kOe0-PsvxUiuxYdifgq8kA4nq0KK8ewCZgO9Fpmgx9J6JHkw@mail.gmail.com>
Message-ID: <995BEE02-11F2-465F-BB83-488BD34006A4@oracle.com>

On Jul 26, 2017, at 11:39 AM, Martin Buchholz <martinrb at google.com> wrote:

> Looks good to me.
> 
> I again forgot that VarHandles are still only whitelisted for java.util.concurrent.

Good.

> I would label this noreg-hard .

Yeah you?re probably correct. I?ll remove the test update from the patch and add that label before pushing it unless I hear objections.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170726/27662717/attachment.html>

From Alan.Bateman at oracle.com  Thu Jul 27 11:05:36 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 27 Jul 2017 12:05:36 +0100
Subject: JDK 10 RFR of 8185092: Data race in FilterOutputStream.close
In-Reply-To: <DBCE209F-FC6F-426A-818E-A13B28CE7207@oracle.com>
References: <DBCE209F-FC6F-426A-818E-A13B28CE7207@oracle.com>
Message-ID: <68dba7e8-e565-acd2-dbcb-46fc0e662a9b@oracle.com>



On 26/07/2017 18:52, Brian Burkhalter wrote:
> :
>
> --- a/src/java.base/share/classes/java/io/FilterOutputStream.java
> +++ b/src/java.base/share/classes/java/io/FilterOutputStream.java
> @@ -25,6 +25,8 @@
>   
>   package java.io;
>   
> +import java.util.concurrent.atomic.AtomicBoolean;
> +
>   /**
>    * This class is the superclass of all classes that filter output
>    * streams. These streams sit on top of an already existing output
> @@ -50,7 +52,7 @@
>       /**
>        * Whether the stream is closed; implicitly initialized to false.
>        */
> -    private boolean closed;
> +    private AtomicBoolean closed = new AtomicBoolean();
>   
>       /**
>        * Creates an output stream filter built on top of the specified
> @@ -162,10 +164,9 @@
>        */
>       @Override
>       public void close() throws IOException {
> -        if (closed) {
> +        if (closed.getAndSet(true)) {
>               return;
>           }
> -        closed = true;
>   
>           Throwable flushException = null;
>           try {
This is probably okay but would be good to check the impact on startup 
(as FileOutputStream is loaded early as part of initializing System.out 
and err).

-Alan


From claes.redestad at oracle.com  Thu Jul 27 13:50:44 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 27 Jul 2017 15:50:44 +0200
Subject: JDK 10 RFR of 8185092: Data race in FilterOutputStream.close
In-Reply-To: <68dba7e8-e565-acd2-dbcb-46fc0e662a9b@oracle.com>
References: <DBCE209F-FC6F-426A-818E-A13B28CE7207@oracle.com>
 <68dba7e8-e565-acd2-dbcb-46fc0e662a9b@oracle.com>
Message-ID: <42f5941b-4a9c-db17-0f06-5d41f7d27645@oracle.com>



On 07/27/2017 01:05 PM, Alan Bateman wrote:
>
> This is probably okay but would be good to check the impact on startup 
> (as FileOutputStream is loaded early as part of initializing 
> System.out and err).
>
> -Alan

Right, it appears FilterOutputStream is initialized in System.initPhase1,
which we're actively trying to optimize for as quick startup as possible
since it executes before some subsystems in the VM.

Adding a dependency on AtomicBoolean loads 21 classes in this sensitive
phase of the initialization (it uses VarHandles internally) and executes
around 58,000 bytecode.

I suggest we instead apply the trick recently applied to FileInputStream
to avoid a similar startup regression and use a volatile boolean:

diff -r ec72be80f81b 
src/java.base/share/classes/java/io/FilterOutputStream.java
--- a/src/java.base/share/classes/java/io/FilterOutputStream.java Thu 
Jul 27 15:07:33 2017 +0200
+++ b/src/java.base/share/classes/java/io/FilterOutputStream.java Thu 
Jul 27 15:47:52 2017 +0200
@@ -50,7 +50,9 @@
      /**
       * Whether the stream is closed; implicitly initialized to false.
       */
-    private boolean closed;
+    private volatile boolean closed;
+
+    private final Object closeLock = new Object();

      /**
       * Creates an output stream filter built on top of the specified
@@ -165,7 +167,12 @@
          if (closed) {
              return;
          }
-        closed = true;
+        synchronized (closeLock) {
+            if (closed) {
+                return;
+            }
+            closed = true;
+        }

          Throwable flushException = null;
          try {

Thanks!

/Claes

From brian.burkhalter at oracle.com  Thu Jul 27 15:28:03 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 27 Jul 2017 08:28:03 -0700
Subject: JDK 10 RFR of 8185092: Data race in FilterOutputStream.close
In-Reply-To: <42f5941b-4a9c-db17-0f06-5d41f7d27645@oracle.com>
References: <DBCE209F-FC6F-426A-818E-A13B28CE7207@oracle.com>
 <68dba7e8-e565-acd2-dbcb-46fc0e662a9b@oracle.com>
 <42f5941b-4a9c-db17-0f06-5d41f7d27645@oracle.com>
Message-ID: <22EC005C-9E56-44D0-947B-5227A5D5BEA6@oracle.com>

On Jul 27, 2017, at 6:50 AM, Claes Redestad <claes.redestad at oracle.com> wrote:

> I suggest we instead apply the trick recently applied to FileInputStream
> to avoid a similar startup regression and use a volatile boolean:

Yes, that is what I suggested as an alternative in the initial review request:

On Jul 26, 2017, at 10:52 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> An alternative would be a volatile boolean and a synchronization block [3].
> [?]
> 
> [3]http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/d93f2fd542b7/src/java.base/share/classes/java/io/FileOutputStream.java#l348

I?ll change the patch accordingly.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170727/6fe4675d/attachment.html>

From claes.redestad at oracle.com  Thu Jul 27 15:29:24 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 27 Jul 2017 17:29:24 +0200
Subject: JDK 10 RFR of 8185092: Data race in FilterOutputStream.close
In-Reply-To: <22EC005C-9E56-44D0-947B-5227A5D5BEA6@oracle.com>
References: <DBCE209F-FC6F-426A-818E-A13B28CE7207@oracle.com>
 <68dba7e8-e565-acd2-dbcb-46fc0e662a9b@oracle.com>
 <42f5941b-4a9c-db17-0f06-5d41f7d27645@oracle.com>
 <22EC005C-9E56-44D0-947B-5227A5D5BEA6@oracle.com>
Message-ID: <656b76c7-7801-d9f5-260a-51f536f4f62c@oracle.com>


On 07/27/2017 05:28 PM, Brian Burkhalter wrote:
> On Jul 27, 2017, at 6:50 AM, Claes Redestad <claes.redestad at oracle.com 
> <mailto:claes.redestad at oracle.com>> wrote:
>
>> I suggest we instead apply the trick recently applied to FileInputStream
>> to avoid a similar startup regression and use a volatile boolean:
>
> Yes, that is what I suggested as an alternative in the initial review 
> request:

Oops, missed that.

>
> On Jul 26, 2017, at 10:52 AM, Brian Burkhalter 
> <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> wrote:
>
>> An alternative would be a volatile boolean and a synchronization 
>> block [3].
>> [?]
>>
>> [3]http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/d93f2fd542b7/src/java.base/share/classes/java/io/FileOutputStream.java#l348
>
> I?ll change the patch accordingly.

Thanks!

/Claes

From brian.burkhalter at oracle.com  Thu Jul 27 19:30:45 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 27 Jul 2017 12:30:45 -0700
Subject: JDK 10 RFR of 8185092: Data race in FilterOutputStream.close
In-Reply-To: <656b76c7-7801-d9f5-260a-51f536f4f62c@oracle.com>
References: <DBCE209F-FC6F-426A-818E-A13B28CE7207@oracle.com>
 <68dba7e8-e565-acd2-dbcb-46fc0e662a9b@oracle.com>
 <42f5941b-4a9c-db17-0f06-5d41f7d27645@oracle.com>
 <22EC005C-9E56-44D0-947B-5227A5D5BEA6@oracle.com>
 <656b76c7-7801-d9f5-260a-51f536f4f62c@oracle.com>
Message-ID: <EBC6EC09-468D-4574-AD1C-74C593A7B548@oracle.com>

On Jul 27, 2017, at 8:29 AM, Claes Redestad <claes.redestad at oracle.com> wrote:

>> I?ll change the patch accordingly.
> 
> Thanks!

Le voila:

--- a/src/java.base/share/classes/java/io/FilterOutputStream.java
+++ b/src/java.base/share/classes/java/io/FilterOutputStream.java
@@ -50,7 +50,12 @@
     /**
      * Whether the stream is closed; implicitly initialized to false.
      */
-    private boolean closed;
+    private volatile boolean closed;
+
+    /**
+     * Object used to prevent a race on the 'closed' instance variable.
+     */
+    private final Object closeLock = new Object();
 
     /**
      * Creates an output stream filter built on top of the specified
@@ -165,7 +170,12 @@
         if (closed) {
             return;
         }
-        closed = true;
+        synchronized (closeLock) {
+            if (closed) {
+                return;
+            }
+            closed = true;
+        }
 
         Throwable flushException = null;
         try {

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170727/2db84551/attachment.html>

From claes.redestad at oracle.com  Thu Jul 27 19:41:44 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 27 Jul 2017 21:41:44 +0200
Subject: JDK 10 RFR of 8185092: Data race in FilterOutputStream.close
In-Reply-To: <EBC6EC09-468D-4574-AD1C-74C593A7B548@oracle.com>
References: <DBCE209F-FC6F-426A-818E-A13B28CE7207@oracle.com>
 <68dba7e8-e565-acd2-dbcb-46fc0e662a9b@oracle.com>
 <42f5941b-4a9c-db17-0f06-5d41f7d27645@oracle.com>
 <22EC005C-9E56-44D0-947B-5227A5D5BEA6@oracle.com>
 <656b76c7-7801-d9f5-260a-51f536f4f62c@oracle.com>
 <EBC6EC09-468D-4574-AD1C-74C593A7B548@oracle.com>
Message-ID: <a67bed74-82d5-1353-87fa-b8bee8f50be5@oracle.com>

Looks good to me!

/Claes

On 2017-07-27 21:30, Brian Burkhalter wrote:
> On Jul 27, 2017, at 8:29 AM, Claes Redestad <claes.redestad at oracle.com 
> <mailto:claes.redestad at oracle.com>> wrote:
>
>>> I?ll change the patch accordingly.
>>
>> Thanks!
>
> Le voila:
>
> --- a/src/java.base/share/classes/java/io/FilterOutputStream.java
> +++ b/src/java.base/share/classes/java/io/FilterOutputStream.java
> @@ -50,7 +50,12 @@
>      /**
>       * Whether the stream is closed; implicitly initialized to false.
>       */
> -    private boolean closed;
> +    private volatile boolean closed;
> +
> +    /**
> +     * Object used to prevent a race on the 'closed' instance variable.
> +     */
> +    private final Object closeLock = new Object();
>
>
>      /**
>       * Creates an output stream filter built on top of the specified
> @@ -165,7 +170,12 @@
>          if (closed) {
>              return;
>          }
> -        closed = true;
> +        synchronized (closeLock) {
> +            if (closed) {
> +                return;
> +            }
> +            closed = true;
> +        }
>
>
>          Throwable flushException = null;
>          try {
>
> Thanks,
>
> Brian


From Alan.Bateman at oracle.com  Thu Jul 27 19:45:08 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 27 Jul 2017 20:45:08 +0100
Subject: JDK 10 RFR of 8185092: Data race in FilterOutputStream.close
In-Reply-To: <a67bed74-82d5-1353-87fa-b8bee8f50be5@oracle.com>
References: <DBCE209F-FC6F-426A-818E-A13B28CE7207@oracle.com>
 <68dba7e8-e565-acd2-dbcb-46fc0e662a9b@oracle.com>
 <42f5941b-4a9c-db17-0f06-5d41f7d27645@oracle.com>
 <22EC005C-9E56-44D0-947B-5227A5D5BEA6@oracle.com>
 <656b76c7-7801-d9f5-260a-51f536f4f62c@oracle.com>
 <EBC6EC09-468D-4574-AD1C-74C593A7B548@oracle.com>
 <a67bed74-82d5-1353-87fa-b8bee8f50be5@oracle.com>
Message-ID: <701565d1-cb7b-5484-dbb6-a3f95c61281d@oracle.com>



On 27/07/2017 20:41, Claes Redestad wrote:
> Looks good to me!
>
Looks good to me too.

-Alan