RE: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

Hi All,

Our most recent version of our DirectIO patch is available at 
http://cr.openjdk.java.net/~kkharbas/8164900/webrev.04/
In this version, we have modified the following items:

1.   Remove ByteBuffer.allocateDirectAligned() and ByteBuffer.isAligned(). 
Instead, using existing APIs alignmentOffset() and alignedSlice()

2.   Use Block Size as the alignment value instead of OS page size

3.   Create a function named getBlockSize from FileStore class

4.   Implement DirectIO for Windows

5.   JTreg test passed for Windows, Linux and OS X with regarding to the 
DirectIO changes we made

Please let us know your comments and feedback. Thank you very much for your 
consideration!

Thanks,
Lucy

From: nio-dev [mailto:nio-dev-boun...@openjdk.java.net] On Behalf Of Lu, Yingqi
Sent: Sunday, November 06, 2016 9:37 AM
To: Alan Bateman <alan.bate...@oracle.com>
Cc: Kharbas, Kishor <kishor.khar...@intel.com>; David Holmes 
<david.hol...@oracle.com>; core-libs-dev@openjdk.java.net; 
nio-...@openjdk.java.net; Thomas Stüfe <thomas.stu...@gmail.com>; Kaczmarek, 
Eric <eric.kaczma...@intel.com>
Subject: Re: Proposal for adding O_DIRECT support into JDK 9

Hi Alan,

Thank you very much for your suggestion. FileStore is a better home for the 
alignment value. We will use It in our next version of the patch and update 
here for review soon.
Thanks,
Lucy

Sent from my iPhone
On Nov 6, 2016, at 9:04 AM, Alan Bateman 
<alan.bate...@oracle.com<mailto:alan.bate...@oracle.com>> wrote:
On 06/11/2016 15:51, Lu, Yingqi wrote:
Another approach might be use ioctl to get the block size and use that as the 
alignment value. I think ioctl is available on UNIX based OSes (please chime in 
if I miss any OS here) and has a similar call for Windows named 
DeviceIoControl. The request code of ioctl is different from OS to OS, but we 
could address that in the native code.

A possible approach (I think I mentioned this in one of the early mails) is to 
have FileStore expose the block size that can be use to align and size the 
buffer.

-Alan

Re: Proposal for adding O_DIRECT support into JDK 9

[Thomas Stüfe]

On Sun, Nov 6, 2016 at 6:04 PM, Alan Bateman 
wrote:

> On 06/11/2016 15:51, Lu, Yingqi wrote:
>
> Another approach might be use ioctl to get the block size and use that as
> the alignment value. I think ioctl is available on UNIX based OSes (please
> chime in if I miss any OS here) and has a similar call for Windows named
> DeviceIoControl. The request code of ioctl is different from OS to OS, but
> we could address that in the native code.
>
> A possible approach (I think I mentioned this in one of the early mails)
> is to have FileStore expose the block size that can be use to align and
> size the buffer.
>
> -Alan
>

And if an OS or a file system driver does not provide information about
block size, one still could poll. E.g. on Linux, attempt to read() at ever
increasing alignments until one does not get EINVAL anymore.

Thomas

Re: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

Hi Alan,

Thank you very much for your suggestion. FileStore is a better home for the 
alignment value. We will use It in our next version of the patch and update 
here for review soon.

Thanks,
Lucy

Sent from my iPhone
On Nov 6, 2016, at 9:04 AM, Alan Bateman 
> wrote:


On 06/11/2016 15:51, Lu, Yingqi wrote:
Another approach might be use ioctl to get the block size and use that as the 
alignment value. I think ioctl is available on UNIX based OSes (please chime in 
if I miss any OS here) and has a similar call for Windows named 
DeviceIoControl. The request code of ioctl is different from OS to OS, but we 
could address that in the native code.

A possible approach (I think I mentioned this in one of the early mails) is to 
have FileStore expose the block size that can be use to align and size the 
buffer.

-Alan

Re: Proposal for adding O_DIRECT support into JDK 9

[Alan Bateman]

On 06/11/2016 15:51, Lu, Yingqi wrote:

Another approach might be use ioctl to get the block size and use that 
as the alignment value. I think ioctl is available on UNIX based OSes 
(please chime in if I miss any OS here) and has a similar call for 
Windows named DeviceIoControl. The request code of ioctl is different 
from OS to OS, but we could address that in the native code.



A possible approach (I think I mentioned this in one of the early mails) 
is to have FileStore expose the block size that can be use to align and 
size the buffer.


-Alan

RE: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

Another approach might be use ioctl to get the block size and use that as the 
alignment value. I think ioctl is available on UNIX based OSes (please chime in 
if I miss any OS here) and has a similar call for Windows named 
DeviceIoControl. The request code of ioctl is different from OS to OS, but we 
could address that in the native code.

What do you all think on this?

Thanks,
Lucy

From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
Sent: Sunday, November 06, 2016 3:22 AM
To: David Holmes <david.hol...@oracle.com>
Cc: Paul Sandoz <paul.san...@oracle.com>; Lu, Yingqi <yingqi...@intel.com>; 
nio-...@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com>; 
core-libs-dev@openjdk.java.net; Kharbas, Kishor <kishor.khar...@intel.com>
Subject: Re: Proposal for adding O_DIRECT support into JDK 9



On Sat, Nov 5, 2016 at 6:42 PM, David Holmes 
<david.hol...@oracle.com<mailto:david.hol...@oracle.com>> wrote:
Hi Paul,

On 5/11/2016 2:58 AM, Paul Sandoz wrote:
Hi Lucy,

I am struggling to find an entirely satisfactory location to place a method 
such as getPageSize, but java.lang.Runtime seems less worse than other places 
:-)

This does not seem an appropriate method to expose in this form at the 
java.lang.Runtime level. If we want a public, platform agnostic API for 
exposing virtual memory page sizes (plural) then we should design such an API 
IMHO.

I absolutely agree. Different memory regions can have different page sizes 
following different rules. The fact that in hotspot coding os::vm_page_size() 
is used in many places as "the pagesize" gave us lots of headaches in the AIX 
port, where we can have up to four different page sizes for heap, stack, text 
and different instances of shared memory. I consider the fact that 
unsafe.pageSize() exists sloppy API design. Even on Linux we can have two page 
sizes within one process, or?

If we really need a generic "pageSize" API this should be designed to cover a 
reasonable large array of OS breeds. IMHO a good generic API should allow me to 
query, given a memory range, its page-size-composition, because within a region 
of memory one may have different page sizes.

Thomas

David

Paul.
On 3 Nov 2016, at 12:49, Lu, Yingqi 
<yingqi...@intel.com<mailto:yingqi...@intel.com>> wrote:

Hi Paul and Peter,

Thank you very much for pointing this out. We did not know about it J

We will modify the patch accordingly and will send it here for review.

Thanks,
Lucy

From: Paul Sandoz [mailto:paul.san...@oracle.com<mailto:paul.san...@oracle.com>]
Sent: Thursday, November 03, 2016 12:46 PM
To: Peter Levart <peter.lev...@gmail.com<mailto:peter.lev...@gmail.com>>
Cc: Lu, Yingqi <yingqi...@intel.com<mailto:yingqi...@intel.com>>; Alan Bateman 
<alan.bate...@oracle.com<mailto:alan.bate...@oracle.com>>; 
nio-...@openjdk.java.net<mailto:nio-...@openjdk.java.net>; Kaczmarek, Eric 
<eric.kaczma...@intel.com<mailto:eric.kaczma...@intel.com>>; 
core-libs-dev@openjdk.java.net<mailto:core-libs-dev@openjdk.java.net>; Kharbas, 
Kishor <kishor.khar...@intel.com<mailto:kishor.khar...@intel.com>>
Subject: Re: Proposal for adding O_DIRECT support into JDK 9

Hi Peter,

Thanks for pointing this out, you beat me to it :-)

Note that the alignment for a unit size corresponding to page size will only be 
stable for direct byte buffers, since for heap byte buffers the GC can move the 
underlying byte array and the alignment properties may change.

Paul.

On 3 Nov 2016, at 12:38, Peter Levart 
<peter.lev...@gmail.com<mailto:peter.lev...@gmail.com>> wrote:

Hi Lucy,

Did you know that in JDK 9 the following two methods have been added to 
java.nio.ByteBuffer:

/** @return  The indexed byte's memory address modulus the unit size
  */
public final int alignmentOffset(int index, int unitSize);

/** @return new byte buffer whose content is a shared and aligned subsequence 
of this buffer's content
  */
public final ByteBuffer alignedSlice(int unitSize);


So you could express your proposed methods ByteBuffer.allocateDirectAligned() 
and ByteBuffer.isAligned() with the above two methods in the following way:

instead of:

ByteBuffer bb = ByteBuffer.allocateDirectAligned(capacity)

you could do:

int pageSize = ...
ByteBuffer bb = ByteBuffer.allocateDirect(capacity + pageSize - 
1).alignedSlice(pageSize);

And instead of:

bb.isAligned()

you could do:

bb.alignmentOffset(pageSize) == 0



The only thing that needs to be added is a public API to return the pageSize 
(i.e. Bits.pageSize()).


What do you think?

Regards, Peter

On 11/03/2016 12:34 AM, Lu, Yingqi wrote:
Hi All,

Our most recent DirectIO patch is available at 
http://cr.openjdk.java.net/~igraves/8164900-3/

In this version, we made following changes:

1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to 
the FileChannelIm

Re: Proposal for adding O_DIRECT support into JDK 9

[Thomas Stüfe]

On Sat, Nov 5, 2016 at 6:42 PM, David Holmes <david.hol...@oracle.com>
wrote:

> Hi Paul,
>
> On 5/11/2016 2:58 AM, Paul Sandoz wrote:
>
>> Hi Lucy,
>>
>> I am struggling to find an entirely satisfactory location to place a
>> method such as getPageSize, but java.lang.Runtime seems less worse than
>> other places :-)
>>
>
> This does not seem an appropriate method to expose in this form at the
> java.lang.Runtime level. If we want a public, platform agnostic API for
> exposing virtual memory page sizes (plural) then we should design such an
> API IMHO.
>
>
I absolutely agree. Different memory regions can have different page sizes
following different rules. The fact that in hotspot coding
os::vm_page_size() is used in many places as "the pagesize" gave us lots of
headaches in the AIX port, where we can have up to four different page
sizes for heap, stack, text and different instances of shared memory. I
consider the fact that unsafe.pageSize() exists sloppy API design. Even on
Linux we can have two page sizes within one process, or?

If we really need a generic "pageSize" API this should be designed to cover
a reasonable large array of OS breeds. IMHO a good generic API should allow
me to query, given a memory range, its page-size-composition, because
within a region of memory one may have different page sizes.

Thomas

David
>
>
> Paul.
>>
>> On 3 Nov 2016, at 12:49, Lu, Yingqi <yingqi...@intel.com> wrote:
>>>
>>> Hi Paul and Peter,
>>>
>>> Thank you very much for pointing this out. We did not know about it J
>>>
>>> We will modify the patch accordingly and will send it here for review.
>>>
>>> Thanks,
>>> Lucy
>>>
>>> From: Paul Sandoz [mailto:paul.san...@oracle.com]
>>> Sent: Thursday, November 03, 2016 12:46 PM
>>> To: Peter Levart <peter.lev...@gmail.com>
>>> Cc: Lu, Yingqi <yingqi...@intel.com>; Alan Bateman <
>>> alan.bate...@oracle.com>; nio-...@openjdk.java.net; Kaczmarek, Eric <
>>> eric.kaczma...@intel.com>; core-libs-dev@openjdk.java.net; Kharbas,
>>> Kishor <kishor.khar...@intel.com>
>>> Subject: Re: Proposal for adding O_DIRECT support into JDK 9
>>>
>>> Hi Peter,
>>>
>>> Thanks for pointing this out, you beat me to it :-)
>>>
>>> Note that the alignment for a unit size corresponding to page size will
>>> only be stable for direct byte buffers, since for heap byte buffers the GC
>>> can move the underlying byte array and the alignment properties may change.
>>>
>>> Paul.
>>>
>>> On 3 Nov 2016, at 12:38, Peter Levart <peter.lev...@gmail.com> wrote:
>>>
>>> Hi Lucy,
>>>
>>> Did you know that in JDK 9 the following two methods have been added to
>>> java.nio.ByteBuffer:
>>>
>>> /** @return  The indexed byte's memory address modulus the unit size
>>>   */
>>> public final int alignmentOffset(int index, int unitSize);
>>>
>>> /** @return new byte buffer whose content is a shared and aligned
>>> subsequence of this buffer's content
>>>   */
>>> public final ByteBuffer alignedSlice(int unitSize);
>>>
>>>
>>> So you could express your proposed methods 
>>> ByteBuffer.allocateDirectAligned()
>>> and ByteBuffer.isAligned() with the above two methods in the following way:
>>>
>>> instead of:
>>>
>>> ByteBuffer bb = ByteBuffer.allocateDirectAligned(capacity)
>>>
>>> you could do:
>>>
>>> int pageSize = ...
>>> ByteBuffer bb = ByteBuffer.allocateDirect(capacity + pageSize -
>>> 1).alignedSlice(pageSize);
>>>
>>> And instead of:
>>>
>>> bb.isAligned()
>>>
>>> you could do:
>>>
>>> bb.alignmentOffset(pageSize) == 0
>>>
>>>
>>>
>>> The only thing that needs to be added is a public API to return the
>>> pageSize (i.e. Bits.pageSize()).
>>>
>>>
>>> What do you think?
>>>
>>> Regards, Peter
>>>
>>> On 11/03/2016 12:34 AM, Lu, Yingqi wrote:
>>> Hi All,
>>>
>>> Our most recent DirectIO patch is available at
>>> http://cr.openjdk.java.net/~igraves/8164900-3/
>>>
>>> In this version, we made following changes:
>>>
>>> 1. Removed the flag "direct" from FileDescriptor class. Instead, moved
>>> it to the FileChannelImpl class.
>>>
>>>

RE: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

Hi Alan and David,

Thank you for your email.

I totally agree that OS kernel supports multiple page sizes. For example, my 
Linux box supports both 4K and 2M pages. Currently, our getAlignment() function 
inside FileChannel/FileChannelImpl calls an existing function 
sun.nio.ch.Util.pageSize() which eventually calls unsafe.pageSize(). I use a 
small Java program to test unsafe.pageSize() with and without the flag " 
-XX:+UseLargePages" on my Linux box, both testing return 4096. 
 
To make DirectIO work, IO size and file position need to be aligned to the disk 
block size. Native memory page size (in our case, 4096) is always a multiple or 
equal of disk block size. That is why we try to use this existing JDK function 
(sun.nio.ch.Util.pageSize()) for the alignment value. To make it simpler, we 
use getAlignment as the function name and put it inside the 
FileChannel/FileChannelImpl.

Please let us know if you have any questions, comments and concerns. Thank you 
very much for your consideration!

Thanks,
Lucy

>-Original Message-
>From: Alan Burlison [mailto:alan.burli...@oracle.com]
>Sent: Saturday, November 05, 2016 1:13 AM
>To: David M. Lloyd <david.ll...@redhat.com>; Paul Sandoz
><paul.san...@oracle.com>; Lu, Yingqi <yingqi...@intel.com>
>Cc: nio-...@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com>;
>core-libs-dev@openjdk.java.net; Kharbas, Kishor <kishor.khar...@intel.com>
>Subject: Re: Proposal for adding O_DIRECT support into JDK 9
>
>On 04/11/2016 18:32, David M. Lloyd wrote:
>
>> I still feel like it could be a problem to have just one simple
>> getPageSize method, given how many CPU architectures and OSes support
>> multiple page sizes.
>
>Yes.
>
>$ pagesize -a
>8192
>65536
>4194304
>268435456
>2147483648
>
>--
>Alan Burlison
>--

Re: Proposal for adding O_DIRECT support into JDK 9

[David Holmes]

Hi Paul,

On 5/11/2016 2:58 AM, Paul Sandoz wrote:

Hi Lucy,

I am struggling to find an entirely satisfactory location to place a method 
such as getPageSize, but java.lang.Runtime seems less worse than other places 
:-)


This does not seem an appropriate method to expose in this form at the 
java.lang.Runtime level. If we want a public, platform agnostic API for 
exposing virtual memory page sizes (plural) then we should design such 
an API IMHO.


David


Paul.


On 3 Nov 2016, at 12:49, Lu, Yingqi <yingqi...@intel.com> wrote:

Hi Paul and Peter,

Thank you very much for pointing this out. We did not know about it J

We will modify the patch accordingly and will send it here for review.

Thanks,
Lucy

From: Paul Sandoz [mailto:paul.san...@oracle.com]
Sent: Thursday, November 03, 2016 12:46 PM
To: Peter Levart <peter.lev...@gmail.com>
Cc: Lu, Yingqi <yingqi...@intel.com>; Alan Bateman <alan.bate...@oracle.com>; 
nio-...@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com>; 
core-libs-dev@openjdk.java.net; Kharbas, Kishor <kishor.khar...@intel.com>
Subject: Re: Proposal for adding O_DIRECT support into JDK 9

Hi Peter,

Thanks for pointing this out, you beat me to it :-)

Note that the alignment for a unit size corresponding to page size will only be 
stable for direct byte buffers, since for heap byte buffers the GC can move the 
underlying byte array and the alignment properties may change.

Paul.

On 3 Nov 2016, at 12:38, Peter Levart <peter.lev...@gmail.com> wrote:

Hi Lucy,

Did you know that in JDK 9 the following two methods have been added to 
java.nio.ByteBuffer:

/** @return  The indexed byte's memory address modulus the unit size
  */
public final int alignmentOffset(int index, int unitSize);

/** @return new byte buffer whose content is a shared and aligned subsequence 
of this buffer's content
  */
public final ByteBuffer alignedSlice(int unitSize);


So you could express your proposed methods ByteBuffer.allocateDirectAligned() 
and ByteBuffer.isAligned() with the above two methods in the following way:

instead of:

ByteBuffer bb = ByteBuffer.allocateDirectAligned(capacity)

you could do:

int pageSize = ...
ByteBuffer bb = ByteBuffer.allocateDirect(capacity + pageSize - 
1).alignedSlice(pageSize);

And instead of:

bb.isAligned()

you could do:

bb.alignmentOffset(pageSize) == 0



The only thing that needs to be added is a public API to return the pageSize 
(i.e. Bits.pageSize()).


What do you think?

Regards, Peter

On 11/03/2016 12:34 AM, Lu, Yingqi wrote:
Hi All,

Our most recent DirectIO patch is available at 
http://cr.openjdk.java.net/~igraves/8164900-3/

In this version, we made following changes:

1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to 
the FileChannelImpl class.

2. Provided a way for user to allocate a page aligned direct ByteBuffer.
1) Added a constructor DirectByteBuffer(int cap, boolean direct) to 
allocate a direct ByteBuffer that is aligned to the page size.
2) Added Util.getTemporaryAlignedDirectBuffer(int size)
3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is 
aligned before doing native IO with it.

3. Moved all the alignment check from C code to Java code (mainly 
FileChannelImpl and IOUtil.java).

4. Made the DirectIO functionality consistent between read and write 
operations. With current version of the patch, user would be responsible for 
the alignment with file offset and IO size.

5. Made the API for DirectIO more extensible to all the supporting platforms.
1) Unix OS specific code are done through UnixConstants.java.template and 
FileChannelImpl.c.
2) Coded and tested for Linux and OS X (OS X testing is done through 
VirtualBox with OS X VM on top of Linux OS).
3) Coded for Solaris. We do not have environment to test it so that we 
commented the changes out.

6. We added 4 test cases following the existing non-direct IO examples.

7. We did jtreg test for the entire nio package and no errors were found due to 
our changes.

Please let us know your feedback and comment. Thank you very much for your time 
and consideration!

Thanks,
Lucy

-Original Message-
From: Alan Bateman [mailto:alan.bate...@oracle.com]
Sent: Monday, October 17, 2016 7:59 AM
To: Lu, Yingqi <yingqi...@intel.com>
Cc: nio-...@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com>;
Kharbas, Kishor <kishor.khar...@intel.com>
Subject: Re: Proposal for adding O_DIRECT support into JDK 9

On 12/10/2016 17:41, Lu, Yingqi wrote:

:

You are correct about the "extra copy" with DirectIO. Will it be acceptable if 
we
add a function "Util.getAlignedTemporaryDirectBuffer" and use that for the
DirectIO operation? In this case, I think we should be able to avoid the 
additional
copy?
Yes, that should work but it still lacks a way for the user to get an aligned 
buffer
and so you will al

Re: Proposal for adding O_DIRECT support into JDK 9

[Alan Burlison]

On 04/11/2016 18:32, David M. Lloyd wrote:


I still feel like it could be a problem to have just one simple
getPageSize method, given how many CPU architectures and OSes support
multiple page sizes.


Yes.

$ pagesize -a
8192
65536
4194304
268435456
2147483648

--
Alan Burlison
--

Re: Proposal for adding O_DIRECT support into JDK 9

[David M. Lloyd]

I still feel like it could be a problem to have just one simple 
getPageSize method, given how many CPU architectures and OSes support 
multiple page sizes.


On 11/04/2016 11:58 AM, Paul Sandoz wrote:

Hi Lucy,

I am struggling to find an entirely satisfactory location to place a method 
such as getPageSize, but java.lang.Runtime seems less worse than other places 
:-)

Paul.


On 3 Nov 2016, at 12:49, Lu, Yingqi <yingqi...@intel.com> wrote:

Hi Paul and Peter,

Thank you very much for pointing this out. We did not know about it J

We will modify the patch accordingly and will send it here for review.

Thanks,
Lucy

From: Paul Sandoz [mailto:paul.san...@oracle.com]
Sent: Thursday, November 03, 2016 12:46 PM
To: Peter Levart <peter.lev...@gmail.com>
Cc: Lu, Yingqi <yingqi...@intel.com>; Alan Bateman <alan.bate...@oracle.com>; 
nio-...@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com>; 
core-libs-dev@openjdk.java.net; Kharbas, Kishor <kishor.khar...@intel.com>
Subject: Re: Proposal for adding O_DIRECT support into JDK 9

Hi Peter,

Thanks for pointing this out, you beat me to it :-)

Note that the alignment for a unit size corresponding to page size will only be 
stable for direct byte buffers, since for heap byte buffers the GC can move the 
underlying byte array and the alignment properties may change.

Paul.

On 3 Nov 2016, at 12:38, Peter Levart <peter.lev...@gmail.com> wrote:

Hi Lucy,

Did you know that in JDK 9 the following two methods have been added to 
java.nio.ByteBuffer:

/** @return  The indexed byte's memory address modulus the unit size
  */
public final int alignmentOffset(int index, int unitSize);

/** @return new byte buffer whose content is a shared and aligned subsequence 
of this buffer's content
  */
public final ByteBuffer alignedSlice(int unitSize);


So you could express your proposed methods ByteBuffer.allocateDirectAligned() 
and ByteBuffer.isAligned() with the above two methods in the following way:

instead of:

ByteBuffer bb = ByteBuffer.allocateDirectAligned(capacity)

you could do:

int pageSize = ...
ByteBuffer bb = ByteBuffer.allocateDirect(capacity + pageSize - 
1).alignedSlice(pageSize);

And instead of:

bb.isAligned()

you could do:

bb.alignmentOffset(pageSize) == 0



The only thing that needs to be added is a public API to return the pageSize 
(i.e. Bits.pageSize()).


What do you think?

Regards, Peter

On 11/03/2016 12:34 AM, Lu, Yingqi wrote:
Hi All,

Our most recent DirectIO patch is available at 
http://cr.openjdk.java.net/~igraves/8164900-3/

In this version, we made following changes:

1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to 
the FileChannelImpl class.

2. Provided a way for user to allocate a page aligned direct ByteBuffer.
1) Added a constructor DirectByteBuffer(int cap, boolean direct) to 
allocate a direct ByteBuffer that is aligned to the page size.
2) Added Util.getTemporaryAlignedDirectBuffer(int size)
3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is 
aligned before doing native IO with it.

3. Moved all the alignment check from C code to Java code (mainly 
FileChannelImpl and IOUtil.java).

4. Made the DirectIO functionality consistent between read and write 
operations. With current version of the patch, user would be responsible for 
the alignment with file offset and IO size.

5. Made the API for DirectIO more extensible to all the supporting platforms.
1) Unix OS specific code are done through UnixConstants.java.template and 
FileChannelImpl.c.
2) Coded and tested for Linux and OS X (OS X testing is done through 
VirtualBox with OS X VM on top of Linux OS).
3) Coded for Solaris. We do not have environment to test it so that we 
commented the changes out.

6. We added 4 test cases following the existing non-direct IO examples.

7. We did jtreg test for the entire nio package and no errors were found due to 
our changes.

Please let us know your feedback and comment. Thank you very much for your time 
and consideration!

Thanks,
Lucy

-Original Message-
From: Alan Bateman [mailto:alan.bate...@oracle.com]
Sent: Monday, October 17, 2016 7:59 AM
To: Lu, Yingqi <yingqi...@intel.com>
Cc: nio-...@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com>;
Kharbas, Kishor <kishor.khar...@intel.com>
Subject: Re: Proposal for adding O_DIRECT support into JDK 9

On 12/10/2016 17:41, Lu, Yingqi wrote:

:

You are correct about the "extra copy" with DirectIO. Will it be acceptable if 
we
add a function "Util.getAlignedTemporaryDirectBuffer" and use that for the
DirectIO operation? In this case, I think we should be able to avoid the 
additional
copy?
Yes, that should work but it still lacks a way for the user to get an aligned 
buffer
and so you will always be copying in and out of an aligned buffer. The other 
thing
is the sizing of the I

RE: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

Hi Paul,

Thank you very much for all your suggestions.

Currently, we add getAlignment() function to FileChannel and  override it in 
FileChannelImpl with details. Basically, it just calls 
sun.nio.ch.Util.pageSize(). 

However, if you think exposing pageSize() from java.lang.Runtime is a better 
approach, we can certainly do that. Please let us know!

Thanks,
Lucy 

>-Original Message-
>From: Paul Sandoz [mailto:paul.san...@oracle.com]
>Sent: Friday, November 04, 2016 9:58 AM
>To: Lu, Yingqi <yingqi...@intel.com>
>Cc: Peter Levart <peter.lev...@gmail.com>; Alan Bateman
><alan.bate...@oracle.com>; nio-...@openjdk.java.net; Kaczmarek, Eric
><eric.kaczma...@intel.com>; core-libs-dev@openjdk.java.net; Kharbas, Kishor
><kishor.khar...@intel.com>
>Subject: Re: Proposal for adding O_DIRECT support into JDK 9
>
>Hi Lucy,
>
>I am struggling to find an entirely satisfactory location to place a method 
>such as
>getPageSize, but java.lang.Runtime seems less worse than other places :-)
>
>Paul.
>
>> On 3 Nov 2016, at 12:49, Lu, Yingqi <yingqi...@intel.com> wrote:
>>
>> Hi Paul and Peter,
>>
>> Thank you very much for pointing this out. We did not know about it J
>>
>> We will modify the patch accordingly and will send it here for review.
>>
>> Thanks,
>> Lucy
>>
>> From: Paul Sandoz [mailto:paul.san...@oracle.com]
>> Sent: Thursday, November 03, 2016 12:46 PM
>> To: Peter Levart <peter.lev...@gmail.com>
>> Cc: Lu, Yingqi <yingqi...@intel.com>; Alan Bateman
>> <alan.bate...@oracle.com>; nio-...@openjdk.java.net; Kaczmarek, Eric
>> <eric.kaczma...@intel.com>; core-libs-dev@openjdk.java.net; Kharbas,
>> Kishor <kishor.khar...@intel.com>
>> Subject: Re: Proposal for adding O_DIRECT support into JDK 9
>>
>> Hi Peter,
>>
>> Thanks for pointing this out, you beat me to it :-)
>>
>> Note that the alignment for a unit size corresponding to page size will only 
>> be
>stable for direct byte buffers, since for heap byte buffers the GC can move the
>underlying byte array and the alignment properties may change.
>>
>> Paul.
>>
>> On 3 Nov 2016, at 12:38, Peter Levart <peter.lev...@gmail.com> wrote:
>>
>> Hi Lucy,
>>
>> Did you know that in JDK 9 the following two methods have been added to
>java.nio.ByteBuffer:
>>
>> /** @return  The indexed byte's memory address modulus the unit size
>>   */
>> public final int alignmentOffset(int index, int unitSize);
>>
>> /** @return new byte buffer whose content is a shared and aligned
>subsequence of this buffer's content
>>   */
>> public final ByteBuffer alignedSlice(int unitSize);
>>
>>
>> So you could express your proposed methods ByteBuffer.allocateDirectAligned()
>and ByteBuffer.isAligned() with the above two methods in the following way:
>>
>> instead of:
>>
>> ByteBuffer bb = ByteBuffer.allocateDirectAligned(capacity)
>>
>> you could do:
>>
>> int pageSize = ...
>> ByteBuffer bb = ByteBuffer.allocateDirect(capacity + pageSize -
>> 1).alignedSlice(pageSize);
>>
>> And instead of:
>>
>> bb.isAligned()
>>
>> you could do:
>>
>> bb.alignmentOffset(pageSize) == 0
>>
>>
>>
>> The only thing that needs to be added is a public API to return the pageSize 
>> (i.e.
>Bits.pageSize()).
>>
>>
>> What do you think?
>>
>> Regards, Peter
>>
>> On 11/03/2016 12:34 AM, Lu, Yingqi wrote:
>> Hi All,
>>
>> Our most recent DirectIO patch is available at
>> http://cr.openjdk.java.net/~igraves/8164900-3/
>>
>> In this version, we made following changes:
>>
>> 1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to 
>> the
>FileChannelImpl class.
>>
>> 2. Provided a way for user to allocate a page aligned direct ByteBuffer.
>> 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to 
>> allocate a
>direct ByteBuffer that is aligned to the page size.
>> 2) Added Util.getTemporaryAlignedDirectBuffer(int size)
>> 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is 
>> aligned
>before doing native IO with it.
>>
>> 3. Moved all the alignment check from C code to Java code (mainly
>FileChannelImpl and IOUtil.java).
>>
>> 4. Made the DirectIO functionality consistent between read and write
>operations. With current version of the patch, user would be responsible for 
>the
>alignment with fi

Re: Proposal for adding O_DIRECT support into JDK 9

[Paul Sandoz]

Hi Lucy,

I am struggling to find an entirely satisfactory location to place a method 
such as getPageSize, but java.lang.Runtime seems less worse than other places 
:-)

Paul.

> On 3 Nov 2016, at 12:49, Lu, Yingqi <yingqi...@intel.com> wrote:
> 
> Hi Paul and Peter,
> 
> Thank you very much for pointing this out. We did not know about it J
> 
> We will modify the patch accordingly and will send it here for review.
> 
> Thanks,
> Lucy
> 
> From: Paul Sandoz [mailto:paul.san...@oracle.com]
> Sent: Thursday, November 03, 2016 12:46 PM
> To: Peter Levart <peter.lev...@gmail.com>
> Cc: Lu, Yingqi <yingqi...@intel.com>; Alan Bateman <alan.bate...@oracle.com>; 
> nio-...@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com>; 
> core-libs-dev@openjdk.java.net; Kharbas, Kishor <kishor.khar...@intel.com>
> Subject: Re: Proposal for adding O_DIRECT support into JDK 9
> 
> Hi Peter,
> 
> Thanks for pointing this out, you beat me to it :-)
> 
> Note that the alignment for a unit size corresponding to page size will only 
> be stable for direct byte buffers, since for heap byte buffers the GC can 
> move the underlying byte array and the alignment properties may change.
> 
> Paul.
> 
> On 3 Nov 2016, at 12:38, Peter Levart <peter.lev...@gmail.com> wrote:
> 
> Hi Lucy,
> 
> Did you know that in JDK 9 the following two methods have been added to 
> java.nio.ByteBuffer:
> 
> /** @return  The indexed byte's memory address modulus the unit size
>   */
> public final int alignmentOffset(int index, int unitSize);
> 
> /** @return new byte buffer whose content is a shared and aligned subsequence 
> of this buffer's content
>   */
> public final ByteBuffer alignedSlice(int unitSize);
> 
> 
> So you could express your proposed methods ByteBuffer.allocateDirectAligned() 
> and ByteBuffer.isAligned() with the above two methods in the following way:
> 
> instead of:
> 
> ByteBuffer bb = ByteBuffer.allocateDirectAligned(capacity)
> 
> you could do:
> 
> int pageSize = ...
> ByteBuffer bb = ByteBuffer.allocateDirect(capacity + pageSize - 
> 1).alignedSlice(pageSize);
> 
> And instead of:
> 
> bb.isAligned()
> 
> you could do:
> 
> bb.alignmentOffset(pageSize) == 0
> 
> 
> 
> The only thing that needs to be added is a public API to return the pageSize 
> (i.e. Bits.pageSize()).
> 
> 
> What do you think?
> 
> Regards, Peter
> 
> On 11/03/2016 12:34 AM, Lu, Yingqi wrote:
> Hi All,
> 
> Our most recent DirectIO patch is available at 
> http://cr.openjdk.java.net/~igraves/8164900-3/
> 
> In this version, we made following changes:
> 
> 1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to 
> the FileChannelImpl class.
> 
> 2. Provided a way for user to allocate a page aligned direct ByteBuffer.
> 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to 
> allocate a direct ByteBuffer that is aligned to the page size.
> 2) Added Util.getTemporaryAlignedDirectBuffer(int size)
> 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is 
> aligned before doing native IO with it.
> 
> 3. Moved all the alignment check from C code to Java code (mainly 
> FileChannelImpl and IOUtil.java).
> 
> 4. Made the DirectIO functionality consistent between read and write 
> operations. With current version of the patch, user would be responsible for 
> the alignment with file offset and IO size.
> 
> 5. Made the API for DirectIO more extensible to all the supporting platforms.
> 1) Unix OS specific code are done through UnixConstants.java.template and 
> FileChannelImpl.c.
> 2) Coded and tested for Linux and OS X (OS X testing is done through 
> VirtualBox with OS X VM on top of Linux OS).
> 3) Coded for Solaris. We do not have environment to test it so that we 
> commented the changes out.
> 
> 6. We added 4 test cases following the existing non-direct IO examples.
> 
> 7. We did jtreg test for the entire nio package and no errors were found due 
> to our changes.
> 
> Please let us know your feedback and comment. Thank you very much for your 
> time and consideration!
> 
> Thanks,
> Lucy
> 
> -Original Message-
> From: Alan Bateman [mailto:alan.bate...@oracle.com]
> Sent: Monday, October 17, 2016 7:59 AM
> To: Lu, Yingqi <yingqi...@intel.com>
> Cc: nio-...@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com>;
> Kharbas, Kishor <kishor.khar...@intel.com>
> Subject: Re: Proposal for adding O_DIRECT support into JDK 9
> 
> On 12/10/2016 17:41, Lu, Yingqi wrote:
> 
> :
> 
> Y

Re: Proposal for adding O_DIRECT support into JDK 9

[Jon V.]

Why not call aligned_alloc for doing page alignment?  It should waste much
less memory.

http://en.cppreference.com/w/c/memory/aligned_alloc

On Thu, Nov 3, 2016 at 8:14 AM, David M. Lloyd <david.ll...@redhat.com>
wrote:

> What happens if you're using large pages?  Are the direct buffers always
> allocated off of small pages?
>
>
> On 11/02/2016 06:34 PM, Lu, Yingqi wrote:
>
>> Hi All,
>>
>> Our most recent DirectIO patch is available at
>> http://cr.openjdk.java.net/~igraves/8164900-3/
>>
>> In this version, we made following changes:
>>
>> 1. Removed the flag "direct" from FileDescriptor class. Instead, moved it
>> to the FileChannelImpl class.
>>
>> 2. Provided a way for user to allocate a page aligned direct ByteBuffer.
>> 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to
>> allocate a direct ByteBuffer that is aligned to the page size.
>> 2) Added Util.getTemporaryAlignedDirectBuffer(int size)
>> 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer
>> is aligned before doing native IO with it.
>>
>> 3. Moved all the alignment check from C code to Java code (mainly
>> FileChannelImpl and IOUtil.java).
>>
>> 4. Made the DirectIO functionality consistent between read and write
>> operations. With current version of the patch, user would be responsible
>> for the alignment with file offset and IO size.
>>
>> 5. Made the API for DirectIO more extensible to all the supporting
>> platforms.
>> 1) Unix OS specific code are done through UnixConstants.java.template
>> and FileChannelImpl.c.
>> 2) Coded and tested for Linux and OS X (OS X testing is done through
>> VirtualBox with OS X VM on top of Linux OS).
>> 3) Coded for Solaris. We do not have environment to test it so that
>> we commented the changes out.
>>
>> 6. We added 4 test cases following the existing non-direct IO examples.
>>
>> 7. We did jtreg test for the entire nio package and no errors were found
>> due to our changes.
>>
>> Please let us know your feedback and comment. Thank you very much for
>> your time and consideration!
>>
>> Thanks,
>> Lucy
>>
>> -Original Message-----
>>> From: Alan Bateman [mailto:alan.bate...@oracle.com]
>>> Sent: Monday, October 17, 2016 7:59 AM
>>> To: Lu, Yingqi <yingqi...@intel.com>
>>> Cc: nio-...@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com
>>> >;
>>> Kharbas, Kishor <kishor.khar...@intel.com>
>>> Subject: Re: Proposal for adding O_DIRECT support into JDK 9
>>>
>>> On 12/10/2016 17:41, Lu, Yingqi wrote:
>>>
>>> :
>>>>
>>>> You are correct about the "extra copy" with DirectIO. Will it be
>>>> acceptable if we
>>>>
>>> add a function "Util.getAlignedTemporaryDirectBuffer" and use that for
>>> the
>>> DirectIO operation? In this case, I think we should be able to avoid the
>>> additional
>>> copy?
>>>
>>>>
>>>> Yes, that should work but it still lacks a way for the user to get an
>>> aligned buffer
>>> and so you will always be copying in and out of an aligned buffer. The
>>> other thing
>>> is the sizing of the I/O operation where I think you will also need a
>>> way to expose
>>> the multiple (or block size) to the user.
>>>
>>> -Alan.
>>>
>>
> --
> - DML
>

RE: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

Hi Paul and Peter,

Thank you very much for pointing this out. We did not know about it :)

We will modify the patch accordingly and will send it here for review.

Thanks,
Lucy

From: Paul Sandoz [mailto:paul.san...@oracle.com]
Sent: Thursday, November 03, 2016 12:46 PM
To: Peter Levart <peter.lev...@gmail.com>
Cc: Lu, Yingqi <yingqi...@intel.com>; Alan Bateman <alan.bate...@oracle.com>; 
nio-...@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com>; 
core-libs-dev@openjdk.java.net; Kharbas, Kishor <kishor.khar...@intel.com>
Subject: Re: Proposal for adding O_DIRECT support into JDK 9

Hi Peter,

Thanks for pointing this out, you beat me to it :-)

Note that the alignment for a unit size corresponding to page size will only be 
stable for direct byte buffers, since for heap byte buffers the GC can move the 
underlying byte array and the alignment properties may change.

Paul.

On 3 Nov 2016, at 12:38, Peter Levart 
<peter.lev...@gmail.com<mailto:peter.lev...@gmail.com>> wrote:

Hi Lucy,

Did you know that in JDK 9 the following two methods have been added to 
java.nio.ByteBuffer:

/** @return  The indexed byte's memory address modulus the unit size
  */
public final int alignmentOffset(int index, int unitSize);

/** @return new byte buffer whose content is a shared and aligned subsequence 
of this buffer's content
  */
public final ByteBuffer alignedSlice(int unitSize);


So you could express your proposed methods ByteBuffer.allocateDirectAligned() 
and ByteBuffer.isAligned() with the above two methods in the following way:

instead of:

ByteBuffer bb = ByteBuffer.allocateDirectAligned(capacity)

you could do:

int pageSize = ...
ByteBuffer bb = ByteBuffer.allocateDirect(capacity + pageSize - 
1).alignedSlice(pageSize);

And instead of:

bb.isAligned()

you could do:

bb.alignmentOffset(pageSize) == 0



The only thing that needs to be added is a public API to return the pageSize 
(i.e. Bits.pageSize()).


What do you think?

Regards, Peter
On 11/03/2016 12:34 AM, Lu, Yingqi wrote:

Hi All,



Our most recent DirectIO patch is available at 
http://cr.openjdk.java.net/~igraves/8164900-3/



In this version, we made following changes:



1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to 
the FileChannelImpl class.



2. Provided a way for user to allocate a page aligned direct ByteBuffer.

1) Added a constructor DirectByteBuffer(int cap, boolean direct) to 
allocate a direct ByteBuffer that is aligned to the page size.

2) Added Util.getTemporaryAlignedDirectBuffer(int size)

3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is 
aligned before doing native IO with it.



3. Moved all the alignment check from C code to Java code (mainly 
FileChannelImpl and IOUtil.java).



4. Made the DirectIO functionality consistent between read and write 
operations. With current version of the patch, user would be responsible for 
the alignment with file offset and IO size.



5. Made the API for DirectIO more extensible to all the supporting platforms.

1) Unix OS specific code are done through UnixConstants.java.template and 
FileChannelImpl.c.

2) Coded and tested for Linux and OS X (OS X testing is done through 
VirtualBox with OS X VM on top of Linux OS).

3) Coded for Solaris. We do not have environment to test it so that we 
commented the changes out.



6. We added 4 test cases following the existing non-direct IO examples.



7. We did jtreg test for the entire nio package and no errors were found due to 
our changes.



Please let us know your feedback and comment. Thank you very much for your time 
and consideration!



Thanks,

Lucy



-Original Message-

From: Alan Bateman [mailto:alan.bate...@oracle.com]

Sent: Monday, October 17, 2016 7:59 AM

To: Lu, Yingqi <yingqi...@intel.com><mailto:yingqi...@intel.com>

Cc: nio-...@openjdk.java.net<mailto:nio-...@openjdk.java.net>; Kaczmarek, Eric 
<eric.kaczma...@intel.com><mailto:eric.kaczma...@intel.com>;

Kharbas, Kishor <kishor.khar...@intel.com><mailto:kishor.khar...@intel.com>

Subject: Re: Proposal for adding O_DIRECT support into JDK 9



On 12/10/2016 17:41, Lu, Yingqi wrote:



:



You are correct about the "extra copy" with DirectIO. Will it be acceptable if 
we

add a function "Util.getAlignedTemporaryDirectBuffer" and use that for the

DirectIO operation? In this case, I think we should be able to avoid the 
additional

copy?

Yes, that should work but it still lacks a way for the user to get an aligned 
buffer

and so you will always be copying in and out of an aligned buffer. The other 
thing

is the sizing of the I/O operation where I think you will also need a way to 
expose

the multiple (or block size) to the user.



-Alan.

Re: Proposal for adding O_DIRECT support into JDK 9

[Paul Sandoz]

Hi Peter,

Thanks for pointing this out, you beat me to it :-)

Note that the alignment for a unit size corresponding to page size will only be 
stable for direct byte buffers, since for heap byte buffers the GC can move the 
underlying byte array and the alignment properties may change.

Paul.

> On 3 Nov 2016, at 12:38, Peter Levart <peter.lev...@gmail.com> wrote:
> 
> Hi Lucy,
> 
> Did you know that in JDK 9 the following two methods have been added to 
> java.nio.ByteBuffer:
> 
> /** @return  The indexed byte's memory address modulus the unit size
>   */
> public final int alignmentOffset(int index, int unitSize);
> 
> /** @return new byte buffer whose content is a shared and aligned subsequence 
> of this buffer's content
>   */
> public final ByteBuffer alignedSlice(int unitSize);
> 
> 
> So you could express your proposed methods ByteBuffer.allocateDirectAligned() 
> and ByteBuffer.isAligned() with the above two methods in the following way:
> 
> instead of:
> 
> ByteBuffer bb = ByteBuffer.allocateDirectAligned(capacity)
> 
> you could do:
> 
> int pageSize = ...
> ByteBuffer bb = ByteBuffer.allocateDirect(capacity + pageSize - 
> 1).alignedSlice(pageSize);
> 
> And instead of:
> 
> bb.isAligned()
> 
> you could do:
> 
> bb.alignmentOffset(pageSize) == 0
> 
> 
> 
> The only thing that needs to be added is a public API to return the pageSize 
> (i.e. Bits.pageSize()).
> 
> 
> What do you think?
> 
> Regards, Peter
> 
> On 11/03/2016 12:34 AM, Lu, Yingqi wrote:
>> Hi All,
>> 
>> Our most recent DirectIO patch is available at 
>> http://cr.openjdk.java.net/~igraves/8164900-3/ 
>> <http://cr.openjdk.java.net/~igraves/8164900-3/>
>> 
>> In this version, we made following changes:
>> 
>> 1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to 
>> the FileChannelImpl class.
>> 
>> 2. Provided a way for user to allocate a page aligned direct ByteBuffer.
>> 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to 
>> allocate a direct ByteBuffer that is aligned to the page size.
>> 2) Added Util.getTemporaryAlignedDirectBuffer(int size)
>> 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is 
>> aligned before doing native IO with it.
>> 
>> 3. Moved all the alignment check from C code to Java code (mainly 
>> FileChannelImpl and IOUtil.java).
>> 
>> 4. Made the DirectIO functionality consistent between read and write 
>> operations. With current version of the patch, user would be responsible for 
>> the alignment with file offset and IO size.
>> 
>> 5. Made the API for DirectIO more extensible to all the supporting platforms.
>> 1) Unix OS specific code are done through UnixConstants.java.template 
>> and FileChannelImpl.c.
>> 2) Coded and tested for Linux and OS X (OS X testing is done through 
>> VirtualBox with OS X VM on top of Linux OS).
>> 3) Coded for Solaris. We do not have environment to test it so that we 
>> commented the changes out.
>> 
>> 6. We added 4 test cases following the existing non-direct IO examples.
>> 
>> 7. We did jtreg test for the entire nio package and no errors were found due 
>> to our changes.
>> 
>> Please let us know your feedback and comment. Thank you very much for your 
>> time and consideration!
>> 
>> Thanks,
>> Lucy
>> 
>>> -Original Message-
>>> From: Alan Bateman [mailto:alan.bate...@oracle.com 
>>> <mailto:alan.bate...@oracle.com>]
>>> Sent: Monday, October 17, 2016 7:59 AM
>>> To: Lu, Yingqi <yingqi...@intel.com> <mailto:yingqi...@intel.com>
>>> Cc: nio-...@openjdk.java.net <mailto:nio-...@openjdk.java.net>; Kaczmarek, 
>>> Eric <eric.kaczma...@intel.com> <mailto:eric.kaczma...@intel.com>;
>>> Kharbas, Kishor <kishor.khar...@intel.com> <mailto:kishor.khar...@intel.com>
>>> Subject: Re: Proposal for adding O_DIRECT support into JDK 9
>>> 
>>> On 12/10/2016 17:41, Lu, Yingqi wrote:
>>> 
>>>> :
>>>> 
>>>> You are correct about the "extra copy" with DirectIO. Will it be 
>>>> acceptable if we
>>> add a function "Util.getAlignedTemporaryDirectBuffer" and use that for the
>>> DirectIO operation? In this case, I think we should be able to avoid the 
>>> additional
>>> copy?
>>> Yes, that should work but it still lacks a way for the user to get an 
>>> aligned buffer
>>> and so you will always be copying in and out of an aligned buffer. The 
>>> other thing
>>> is the sizing of the I/O operation where I think you will also need a way 
>>> to expose
>>> the multiple (or block size) to the user.
>>> 
>>> -Alan.
> 

Re: Proposal for adding O_DIRECT support into JDK 9

[Peter Levart]

Hi Lucy,

Did you know that in JDK 9 the following two methods have been added to 
java.nio.ByteBuffer:


/** @return  The indexed byte's memory address modulus the unit size
  */
public final int alignmentOffset(int index, int unitSize);

/** @return new byte buffer whose content is a shared and aligned 
subsequence of this buffer's content

  */
public final ByteBuffer alignedSlice(int unitSize);


So you could express your proposed methods 
ByteBuffer.allocateDirectAligned() and ByteBuffer.isAligned() with the 
above two methods in the following way:


instead of:

ByteBuffer bb = ByteBuffer.allocateDirectAligned(capacity)

you could do:

int pageSize = ...
ByteBuffer bb = ByteBuffer.allocateDirect(capacity + pageSize - 
1).alignedSlice(pageSize);


And instead of:

bb.isAligned()

you could do:

bb.alignmentOffset(pageSize) == 0



The only thing that needs to be added is a public API to return the 
pageSize (i.e. Bits.pageSize()).



What do you think?

Regards, Peter

On 11/03/2016 12:34 AM, Lu, Yingqi wrote:

Hi All,

Our most recent DirectIO patch is available at 
http://cr.openjdk.java.net/~igraves/8164900-3/

In this version, we made following changes:

1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to 
the FileChannelImpl class.

2. Provided a way for user to allocate a page aligned direct ByteBuffer.
 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to 
allocate a direct ByteBuffer that is aligned to the page size.
 2) Added Util.getTemporaryAlignedDirectBuffer(int size)
 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is 
aligned before doing native IO with it.

3. Moved all the alignment check from C code to Java code (mainly 
FileChannelImpl and IOUtil.java).

4. Made the DirectIO functionality consistent between read and write 
operations. With current version of the patch, user would be responsible for 
the alignment with file offset and IO size.

5. Made the API for DirectIO more extensible to all the supporting platforms.
 1) Unix OS specific code are done through UnixConstants.java.template and 
FileChannelImpl.c.
 2) Coded and tested for Linux and OS X (OS X testing is done through 
VirtualBox with OS X VM on top of Linux OS).
 3) Coded for Solaris. We do not have environment to test it so that we 
commented the changes out.

6. We added 4 test cases following the existing non-direct IO examples.

7. We did jtreg test for the entire nio package and no errors were found due to 
our changes.

Please let us know your feedback and comment. Thank you very much for your time 
and consideration!

Thanks,
Lucy


-Original Message-
From: Alan Bateman [mailto:alan.bate...@oracle.com]
Sent: Monday, October 17, 2016 7:59 AM
To: Lu, Yingqi <yingqi...@intel.com>
Cc: nio-...@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com>;
Kharbas, Kishor <kishor.khar...@intel.com>
Subject: Re: Proposal for adding O_DIRECT support into JDK 9

On 12/10/2016 17:41, Lu, Yingqi wrote:


:

You are correct about the "extra copy" with DirectIO. Will it be acceptable if 
we

add a function "Util.getAlignedTemporaryDirectBuffer" and use that for the
DirectIO operation? In this case, I think we should be able to avoid the 
additional
copy?
Yes, that should work but it still lacks a way for the user to get an aligned 
buffer
and so you will always be copying in and out of an aligned buffer. The other 
thing
is the sizing of the I/O operation where I think you will also need a way to 
expose
the multiple (or block size) to the user.

-Alan.

RE: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

I think DirectByteBuffer do not use large page. Please refer to 
https://bugs.openjdk.java.net/browse/JDK-8021829 for more details.

Our code changes are done for alignment. I think they should not impact the 
usage of either small pages or large pages. 

Thanks,
Lucy

>-Original Message-
>From: David M. Lloyd [mailto:david.ll...@redhat.com]
>Sent: Thursday, November 03, 2016 5:15 AM
>To: Lu, Yingqi <yingqi...@intel.com>; Alan Bateman <alan.bate...@oracle.com>
>Cc: nio-...@openjdk.java.net; Kharbas, Kishor <kishor.khar...@intel.com>;
>core-libs-dev@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com>
>Subject: Re: Proposal for adding O_DIRECT support into JDK 9
>
>What happens if you're using large pages?  Are the direct buffers always
>allocated off of small pages?
>
>On 11/02/2016 06:34 PM, Lu, Yingqi wrote:
>> Hi All,
>>
>> Our most recent DirectIO patch is available at
>> http://cr.openjdk.java.net/~igraves/8164900-3/
>>
>> In this version, we made following changes:
>>
>> 1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to 
>> the
>FileChannelImpl class.
>>
>> 2. Provided a way for user to allocate a page aligned direct ByteBuffer.
>> 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to 
>> allocate a
>direct ByteBuffer that is aligned to the page size.
>> 2) Added Util.getTemporaryAlignedDirectBuffer(int size)
>> 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is 
>> aligned
>before doing native IO with it.
>>
>> 3. Moved all the alignment check from C code to Java code (mainly
>FileChannelImpl and IOUtil.java).
>>
>> 4. Made the DirectIO functionality consistent between read and write
>operations. With current version of the patch, user would be responsible for 
>the
>alignment with file offset and IO size.
>>
>> 5. Made the API for DirectIO more extensible to all the supporting platforms.
>> 1) Unix OS specific code are done through UnixConstants.java.template and
>FileChannelImpl.c.
>> 2) Coded and tested for Linux and OS X (OS X testing is done through
>VirtualBox with OS X VM on top of Linux OS).
>> 3) Coded for Solaris. We do not have environment to test it so that we
>commented the changes out.
>>
>> 6. We added 4 test cases following the existing non-direct IO examples.
>>
>> 7. We did jtreg test for the entire nio package and no errors were found due 
>> to
>our changes.
>>
>> Please let us know your feedback and comment. Thank you very much for your
>time and consideration!
>>
>> Thanks,
>> Lucy
>>
>>> -----Original Message-----
>>> From: Alan Bateman [mailto:alan.bate...@oracle.com]
>>> Sent: Monday, October 17, 2016 7:59 AM
>>> To: Lu, Yingqi <yingqi...@intel.com>
>>> Cc: nio-...@openjdk.java.net; Kaczmarek, Eric
>>> <eric.kaczma...@intel.com>; Kharbas, Kishor
>>> <kishor.khar...@intel.com>
>>> Subject: Re: Proposal for adding O_DIRECT support into JDK 9
>>>
>>> On 12/10/2016 17:41, Lu, Yingqi wrote:
>>>
>>>> :
>>>>
>>>> You are correct about the "extra copy" with DirectIO. Will it be
>>>> acceptable if we
>>> add a function "Util.getAlignedTemporaryDirectBuffer" and use that
>>> for the DirectIO operation? In this case, I think we should be able
>>> to avoid the additional copy?
>>>>
>>> Yes, that should work but it still lacks a way for the user to get an
>>> aligned buffer and so you will always be copying in and out of an
>>> aligned buffer. The other thing is the sizing of the I/O operation
>>> where I think you will also need a way to expose the multiple (or block 
>>> size) to
>the user.
>>>
>>> -Alan.
>
>--
>- DML

RE: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

We tried to minimize the changes to native C code and put alignment at Java 
level. We borrow the same approach being used for VM.isDirectMemoryPageAligned 
here for DirectByteBuffer alignment.

Thanks,
Lucy

From: Jon V. [mailto:sybersn...@gmail.com]
Sent: Thursday, November 03, 2016 5:23 AM
To: David M. Lloyd <david.ll...@redhat.com>
Cc: Lu, Yingqi <yingqi...@intel.com>; Alan Bateman <alan.bate...@oracle.com>; 
nio-...@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com>; 
core-libs-dev@openjdk.java.net; Kharbas, Kishor <kishor.khar...@intel.com>
Subject: Re: Proposal for adding O_DIRECT support into JDK 9

Why not call aligned_alloc for doing page alignment?  It should waste much less 
memory.

http://en.cppreference.com/w/c/memory/aligned_alloc

On Thu, Nov 3, 2016 at 8:14 AM, David M. Lloyd 
<david.ll...@redhat.com<mailto:david.ll...@redhat.com>> wrote:
What happens if you're using large pages?  Are the direct buffers always 
allocated off of small pages?


On 11/02/2016 06:34 PM, Lu, Yingqi wrote:
Hi All,

Our most recent DirectIO patch is available at 
http://cr.openjdk.java.net/~igraves/8164900-3/

In this version, we made following changes:

1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to 
the FileChannelImpl class.

2. Provided a way for user to allocate a page aligned direct ByteBuffer.
1) Added a constructor DirectByteBuffer(int cap, boolean direct) to 
allocate a direct ByteBuffer that is aligned to the page size.
2) Added Util.getTemporaryAlignedDirectBuffer(int size)
3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is 
aligned before doing native IO with it.

3. Moved all the alignment check from C code to Java code (mainly 
FileChannelImpl and IOUtil.java).

4. Made the DirectIO functionality consistent between read and write 
operations. With current version of the patch, user would be responsible for 
the alignment with file offset and IO size.

5. Made the API for DirectIO more extensible to all the supporting platforms.
1) Unix OS specific code are done through UnixConstants.java.template and 
FileChannelImpl.c.
2) Coded and tested for Linux and OS X (OS X testing is done through 
VirtualBox with OS X VM on top of Linux OS).
3) Coded for Solaris. We do not have environment to test it so that we 
commented the changes out.

6. We added 4 test cases following the existing non-direct IO examples.

7. We did jtreg test for the entire nio package and no errors were found due to 
our changes.

Please let us know your feedback and comment. Thank you very much for your time 
and consideration!

Thanks,
Lucy
-Original Message-
From: Alan Bateman 
[mailto:alan.bate...@oracle.com<mailto:alan.bate...@oracle.com>]
Sent: Monday, October 17, 2016 7:59 AM
To: Lu, Yingqi <yingqi...@intel.com<mailto:yingqi...@intel.com>>
Cc: nio-...@openjdk.java.net<mailto:nio-...@openjdk.java.net>; Kaczmarek, Eric 
<eric.kaczma...@intel.com<mailto:eric.kaczma...@intel.com>>;
Kharbas, Kishor <kishor.khar...@intel.com<mailto:kishor.khar...@intel.com>>
Subject: Re: Proposal for adding O_DIRECT support into JDK 9

On 12/10/2016 17:41, Lu, Yingqi wrote:
:

You are correct about the "extra copy" with DirectIO. Will it be acceptable if 
we
add a function "Util.getAlignedTemporaryDirectBuffer" and use that for the
DirectIO operation? In this case, I think we should be able to avoid the 
additional
copy?

Yes, that should work but it still lacks a way for the user to get an aligned 
buffer
and so you will always be copying in and out of an aligned buffer. The other 
thing
is the sizing of the I/O operation where I think you will also need a way to 
expose
the multiple (or block size) to the user.

-Alan.

--
- DML

Re: Proposal for adding O_DIRECT support into JDK 9

[David M. Lloyd]

What happens if you're using large pages?  Are the direct buffers always 
allocated off of small pages?


On 11/02/2016 06:34 PM, Lu, Yingqi wrote:

Hi All,

Our most recent DirectIO patch is available at 
http://cr.openjdk.java.net/~igraves/8164900-3/

In this version, we made following changes:

1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to 
the FileChannelImpl class.

2. Provided a way for user to allocate a page aligned direct ByteBuffer.
1) Added a constructor DirectByteBuffer(int cap, boolean direct) to 
allocate a direct ByteBuffer that is aligned to the page size.
2) Added Util.getTemporaryAlignedDirectBuffer(int size)
3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is 
aligned before doing native IO with it.

3. Moved all the alignment check from C code to Java code (mainly 
FileChannelImpl and IOUtil.java).

4. Made the DirectIO functionality consistent between read and write 
operations. With current version of the patch, user would be responsible for 
the alignment with file offset and IO size.

5. Made the API for DirectIO more extensible to all the supporting platforms.
1) Unix OS specific code are done through UnixConstants.java.template and 
FileChannelImpl.c.
2) Coded and tested for Linux and OS X (OS X testing is done through 
VirtualBox with OS X VM on top of Linux OS).
3) Coded for Solaris. We do not have environment to test it so that we 
commented the changes out.

6. We added 4 test cases following the existing non-direct IO examples.

7. We did jtreg test for the entire nio package and no errors were found due to 
our changes.

Please let us know your feedback and comment. Thank you very much for your time 
and consideration!

Thanks,
Lucy


-Original Message-
From: Alan Bateman [mailto:alan.bate...@oracle.com]
Sent: Monday, October 17, 2016 7:59 AM
To: Lu, Yingqi <yingqi...@intel.com>
Cc: nio-...@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com>;
Kharbas, Kishor <kishor.khar...@intel.com>
Subject: Re: Proposal for adding O_DIRECT support into JDK 9

On 12/10/2016 17:41, Lu, Yingqi wrote:


:

You are correct about the "extra copy" with DirectIO. Will it be acceptable if 
we

add a function "Util.getAlignedTemporaryDirectBuffer" and use that for the
DirectIO operation? In this case, I think we should be able to avoid the 
additional
copy?



Yes, that should work but it still lacks a way for the user to get an aligned 
buffer
and so you will always be copying in and out of an aligned buffer. The other 
thing
is the sizing of the I/O operation where I think you will also need a way to 
expose
the multiple (or block size) to the user.

-Alan.


--
- DML

RE: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

Hi All,

Our most recent DirectIO patch is available at 
http://cr.openjdk.java.net/~igraves/8164900-3/

In this version, we made following changes:

1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to 
the FileChannelImpl class.

2. Provided a way for user to allocate a page aligned direct ByteBuffer.
1) Added a constructor DirectByteBuffer(int cap, boolean direct) to 
allocate a direct ByteBuffer that is aligned to the page size. 
2) Added Util.getTemporaryAlignedDirectBuffer(int size)
3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is 
aligned before doing native IO with it.

3. Moved all the alignment check from C code to Java code (mainly 
FileChannelImpl and IOUtil.java).

4. Made the DirectIO functionality consistent between read and write 
operations. With current version of the patch, user would be responsible for 
the alignment with file offset and IO size. 

5. Made the API for DirectIO more extensible to all the supporting platforms.
1) Unix OS specific code are done through UnixConstants.java.template and 
FileChannelImpl.c.
2) Coded and tested for Linux and OS X (OS X testing is done through 
VirtualBox with OS X VM on top of Linux OS).
3) Coded for Solaris. We do not have environment to test it so that we 
commented the changes out. 

6. We added 4 test cases following the existing non-direct IO examples.

7. We did jtreg test for the entire nio package and no errors were found due to 
our changes.

Please let us know your feedback and comment. Thank you very much for your time 
and consideration!

Thanks,
Lucy

>-Original Message-
>From: Alan Bateman [mailto:alan.bate...@oracle.com]
>Sent: Monday, October 17, 2016 7:59 AM
>To: Lu, Yingqi <yingqi...@intel.com>
>Cc: nio-...@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com>;
>Kharbas, Kishor <kishor.khar...@intel.com>
>Subject: Re: Proposal for adding O_DIRECT support into JDK 9
>
>On 12/10/2016 17:41, Lu, Yingqi wrote:
>
>> :
>>
>> You are correct about the "extra copy" with DirectIO. Will it be acceptable 
>> if we
>add a function "Util.getAlignedTemporaryDirectBuffer" and use that for the
>DirectIO operation? In this case, I think we should be able to avoid the 
>additional
>copy?
>>
>Yes, that should work but it still lacks a way for the user to get an aligned 
>buffer
>and so you will always be copying in and out of an aligned buffer. The other 
>thing
>is the sizing of the I/O operation where I think you will also need a way to 
>expose
>the multiple (or block size) to the user.
>
>-Alan.

RE: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

Alan,

Thank you for the feedback. We will come up with a more generic API that is 
flexible for supporting all the platforms that have DirectIO. Will send it here 
for review soon.

Thanks,
Lucy

>-Original Message-
>From: Alan Burlison [mailto:alan.burli...@oracle.com]
>Sent: Friday, October 14, 2016 1:28 AM
>To: Lu, Yingqi <yingqi...@intel.com>; Brian Burkhalter
><brian.burkhal...@oracle.com>
>Cc: Kharbas, Kishor <kishor.khar...@intel.com>; nio-...@openjdk.java.net;
>core-libs-dev@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com>
>Subject: Re: Proposal for adding O_DIRECT support into JDK 9
>
>As has been pointed out already, platforms other than Linux provide similar
>functionality, yet this proposal does not provide any support for them. Even if
>such support isn't added initially, the APIs added for the Linux implementation
>should be generic enough that direct IO support could be added for other
>platforms in the future, and that Java code using direct IO on Linux would work
>on other direct IO enabled platforms as well. My concern is that the proposed
>APIs are too Linux-specific to make that possible.
>
>I'm well aware of the issues in things like Hadoop and Apache Spark, their 
>over-
>reliance on platform-specific functionality and native code has made it 
>extremely
>difficult to get them to work well on platforms other than Linux/x86. We should
>not make the same mistake in Java itself.
>
>--
>Alan Burlison
>--

Re: Proposal for adding O_DIRECT support into JDK 9

[Alan Burlison]

As has been pointed out already, platforms other than Linux provide 
similar functionality, yet this proposal does not provide any support 
for them. Even if such support isn't added initially, the APIs added for 
the Linux implementation should be generic enough that direct IO support 
could be added for other platforms in the future, and that Java code 
using direct IO on Linux would work on other direct IO enabled platforms 
as well. My concern is that the proposed APIs are too Linux-specific to 
make that possible.


I'm well aware of the issues in things like Hadoop and Apache Spark, 
their over-reliance on platform-specific functionality and native code 
has made it extremely difficult to get them to work well on platforms 
other than Linux/x86. We should not make the same mistake in Java itself.


--
Alan Burlison
--

Re: Proposal for adding O_DIRECT support into JDK 9

[Brian Burkhalter]

An interesting comparison of approaches on a Linux server and an OS X client is 
given here:

http://adityaramesh.com/io_benchmark/

Brian

On Oct 13, 2016, at 3:09 PM, e...@zusammenkunft.net wrote:

> The question is, if support for fadvice() would be more flexible (and 
> somewhat saner).
> 
> And of course real async fio .)

RE: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

O_DIRECT is widely adopted in applications designed for high IO throughput, 
such as webservers and Databases. It bypasses filesystem cache and Linux 
readahead buffer which some time slow down the throughput and cause 
unpredictable IO performance. As an example, we recently measured on our Apache 
Cassandra database (one of the most popular distributed database systems 
written in Java) on default buffered IO, lowering readahead buffer from 128KB 
(default) to 8KB improves throughout by up to 4X. This is a typical usage for 
DirectIO and we expect to see even greater gains by doing that. Another example 
is we have enabled Hadoop Distributed File System (HDFS) with O_DIRECT through 
native calls and also measure significant performance gains running a cloud 
workload. It would be really important to have O_DIRECT supported by Java so 
that all Java based applications can take advantage of it.

We agree on the other hand, O_DIRECT has certain limitations. That is why it is 
normally recommended to be used as a performance option. Our purpose is to 
enable it inside Java and provide the application writers a uniform and secure 
way to use it. All the limitations apply to native applications as well. 
1. Regarding to alignment restriction, I cross checked with our kernel experts, 
and we think it is safe to align the memory buffer used by DirectIO to the 
kernel page size. 

2. In term of having O_DIRECT I/O running concurrently with fork(2) on 
privately mapped memory buffer, the issue can be solved by creating DirectIO 
memory buffer using shmat(2) or mmap(2) with the MAP_SHARED flag. 
Alternatively, MADV_DONTFORK with madvise(2) can be used on the memory buffer 
to avoid the issue as well. Details can be find 
http://man7.org/linux/man-pages/man2/open.2.html

3. Combination of DirectIO and BufferedIO on the same file is not recommended 
for performance reason. However, we think application writers should be 
familiar with all of these before using it.

Now, we are planning to do the following changes to the existing patch, hope it 
will be structured a little better this way :-)
1. Create a function to allocate aligned DirectByteBuffer and use it for Direct 
I/O (default is to use DirectByteBuffer as well, but not aligned). The buffer 
will be aligned to page boundary. There are some existing code in 
Direct-X-Buffer.java.template for VM.isDirectMemoryPageAligned. We will follow 
this as an example. We think this will address the "extra copy" issue in the 
last version of the patch.

2. Move all the changes to FileDispatcherImpl.c to Java level. 

3. Remove the changes to FileDescriptor and do the DirectIO check inside 
FileChannelImpl.

Thanks,
Lucy

>-Original Message-
>From: Alan Burlison [mailto:alan.burli...@oracle.com]
>Sent: Thursday, October 13, 2016 5:20 AM
>To: Brian Burkhalter <brian.burkhal...@oracle.com>; Lu, Yingqi
><yingqi...@intel.com>
>Cc: Kharbas, Kishor <kishor.khar...@intel.com>; nio-...@openjdk.java.net;
>core-libs-dev@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com>
>Subject: Re: Proposal for adding O_DIRECT support into JDK 9
>
>On 06/10/2016 00:31, Brian Burkhalter wrote:
>
>> Given that the functionality of O_DIRECT on Linux appears to be
>> supported by other interfaces on OS X, Solaris, and Windows, I wonder
>> whether the patch will need to be refactored in some way to
>> accommodate these other operating systems? For reference it looks as
>> if direct I/O on OS X uses the F_NOCACHE command of fcntl(2) [1]
>> (although per some online comments this might have some problems),
>> Solaris uses the advice argument of directio(3c) [2], and Windows uses
>> a combination of flags passed to CreateFile() [3, 4].
>
>The Linux open(2) manpage contains a long list of warnings about O_DIRECT,
>including:
>
>--
>In Linux alignment restrictions vary by filesystem and kernel version and 
>might be
>absent entirely.  However there is currently no filesystem-independent 
>interface
>for an application to discover these restrictions for a given file or 
>filesystem.
>--
>
>--
>O_DIRECT I/Os should never be run concurrently with the fork(2) system call, if
>the memory buffer is a private mapping (i.e., any mapping created with the
>mmap(2) MAP_PRIVATE flag; this includes memory allocated on the heap and
>statically allocated buffers). Any such I/Os, whether submitted via an
>asynchronous I/O interface or from another thread in the process, should be
>completed before
>fork(2) is called. Failure to do so can result in data corruption and undefined
>behavior in parent and child processes.
>--
>
>--
>Applications should avoid mixing O_DIRECT and normal I/O to the same file, and
>especially to overlapping byte regions in the same file.
>Even w

Re: Proposal for adding O_DIRECT support into JDK 9

[ecki]

The question is, if support for fadvice() would be more flexible (and somewhat 
saner).

And of course real async fio .)

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Alan Burlison
Gesendet: Donnerstag, 13. Oktober 2016 14:30
An: Brian Burkhalter; Lu, Yingqi
Cc: nio-...@openjdk.java.net; Kaczmarek, Eric; core-libs-dev@openjdk.java.net; 
Kharbas, Kishor
Betreff: Re: Proposal for adding O_DIRECT support into JDK 9

On 06/10/2016 00:31, Brian Burkhalter wrote:

> Given that the functionality of O_DIRECT on Linux appears to be
> supported by other interfaces on OS X, Solaris, and Windows, I wonder
> whether the patch will need to be refactored in some way to
> accommodate these other operating systems? For reference it looks as
> if direct I/O on OS X uses the F_NOCACHE command of fcntl(2) [1]
> (although per some online comments this might have some problems),
> Solaris uses the advice argument of directio(3c) [2], and Windows
> uses a combination of flags passed to CreateFile() [3, 4].

The Linux open(2) manpage contains a long list of warnings about 
O_DIRECT, including:

--
In Linux alignment restrictions vary by filesystem and kernel version 
and might be absent entirely.  However there is currently no 
filesystem-independent interface for an application to discover these 
restrictions for a given file or filesystem.
--

--
O_DIRECT I/Os should never be run concurrently with the fork(2) system
call, if the memory buffer is a private mapping (i.e., any
mapping created with the mmap(2) MAP_PRIVATE flag; this includes
memory allocated on the heap and statically allocated buffers). Any
such I/Os, whether submitted via an asynchronous I/O interface or
from another thread in the process, should be completed before
fork(2) is called. Failure to do so can result in data corruption
and undefined behavior in parent and child processes.
--

--
Applications should avoid mixing O_DIRECT and normal I/O to the same
file, and especially to overlapping byte regions in the same file.
Even when the filesystem correctly handles the coherency issues in
this situation, overall I/O throughput is likely to be slower than
using either mode alone. Likewise, applications should avoid mixing
mmap(2) of files with direct I/O to the same files.
--

--
  "The thing that has always disturbed me about O_DIRECT is that
the whole interface is just stupid, and was probably designed
by a deranged monkey on some serious mind-controlling
substances." - Linus
--

Adding support for O_DIRECT has a far wider impact than adding just 
another IO handle flag. As such I'm opposed to this change as it seems 
to be prone to cause hard-to-diagnose failures on Linux and it is also 
specific to just Linux.

-- 
Alan Burlison
--

Re: Proposal for adding O_DIRECT support into JDK 9

[Alan Burlison]

On 06/10/2016 00:31, Brian Burkhalter wrote:


Given that the functionality of O_DIRECT on Linux appears to be
supported by other interfaces on OS X, Solaris, and Windows, I wonder
whether the patch will need to be refactored in some way to
accommodate these other operating systems? For reference it looks as
if direct I/O on OS X uses the F_NOCACHE command of fcntl(2) [1]
(although per some online comments this might have some problems),
Solaris uses the advice argument of directio(3c) [2], and Windows
uses a combination of flags passed to CreateFile() [3, 4].


The Linux open(2) manpage contains a long list of warnings about 
O_DIRECT, including:


--
In Linux alignment restrictions vary by filesystem and kernel version 
and might be absent entirely.  However there is currently no 
filesystem-independent interface for an application to discover these 
restrictions for a given file or filesystem.

--

--
O_DIRECT I/Os should never be run concurrently with the fork(2) system
call, if the memory buffer is a private mapping (i.e., any
mapping created with the mmap(2) MAP_PRIVATE flag; this includes
memory allocated on the heap and statically allocated buffers). Any
such I/Os, whether submitted via an asynchronous I/O interface or
from another thread in the process, should be completed before
fork(2) is called. Failure to do so can result in data corruption
and undefined behavior in parent and child processes.
--

--
Applications should avoid mixing O_DIRECT and normal I/O to the same
file, and especially to overlapping byte regions in the same file.
Even when the filesystem correctly handles the coherency issues in
this situation, overall I/O throughput is likely to be slower than
using either mode alone. Likewise, applications should avoid mixing
mmap(2) of files with direct I/O to the same files.
--

--
 "The thing that has always disturbed me about O_DIRECT is that
the whole interface is just stupid, and was probably designed
by a deranged monkey on some serious mind-controlling
substances." - Linus
--

Adding support for O_DIRECT has a far wider impact than adding just 
another IO handle flag. As such I'm opposed to this change as it seems 
to be prone to cause hard-to-diagnose failures on Linux and it is also 
specific to just Linux.


--
Alan Burlison
--

Re: Proposal for adding O_DIRECT support into JDK 9

[Brian Burkhalter]

Hi Lucy,

On Oct 4, 2016, at 5:35 PM, Lu, Yingqi  wrote:

> Thank you very much for reviewing the patch and providing the detailed 
> error/warning messages. They are very helpful!

You are welcome.

> We will look into the issues and solve them in the next version of the patch. 
> Test cases for O_DIRECT and modified copyright year will be added in next 
> version too.

Given that the functionality of O_DIRECT on Linux appears to be supported by 
other interfaces on OS X, Solaris, and Windows, I wonder whether the patch will 
need to be refactored in some way to accommodate these other operating systems? 
For reference it looks as if direct I/O on OS X uses the F_NOCACHE command of 
fcntl(2) [1] (although per some online comments this might have some problems), 
Solaris uses the advice argument of directio(3c) [2], and Windows uses a 
combination of flags passed to CreateFile() [3, 4].

Thanks,

Brian

[1] 
https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man2/fcntl.2.html
[2] https://docs.oracle.com/cd/E26505_01/html/816-5168/directio-3c.html
[3] https://support.microsoft.com/en-us/kb/99794
[4] 
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx

RE: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

Hi Brain,

Thank you very much for reviewing the patch and providing the detailed 
error/warning messages. They are very helpful!

We will look into the issues and solve them in the next version of the patch. 
Test cases for O_DIRECT and modified copyright year will be added in next 
version too.

Thanks,
Lucy


From: Brian Burkhalter [mailto:brian.burkhal...@oracle.com]
Sent: Tuesday, October 04, 2016 5:06 PM
To: Lu, Yingqi <yingqi...@intel.com>
Cc: Langer, Christoph <christoph.lan...@sap.com>; Alan Bateman 
<alan.bate...@oracle.com>; core-libs-dev@openjdk.java.net; 
nio-...@openjdk.java.net; Kharbas, Kishor <kishor.khar...@intel.com>; 
Kaczmarek, Eric <eric.kaczma...@intel.com>
Subject: Re: Proposal for adding O_DIRECT support into JDK 9

Hi Lucy,

On Oct 4, 2016, at 10:24 AM, Lu, Yingqi 
<yingqi...@intel.com<mailto:yingqi...@intel.com>> wrote:


Anyone else has any feedback/comments?

I looked over the 8164900-2 patch and did not see any conceptual problems per 
se. I did not however scrutinize all the detailed changes, especially the more 
extensive ones in FileDispatcherImpl.c. I did however run the patch through our 
regression tests for IO and NIO and encountered some problems. Firstly the 
patch breaks the build on OS X [1], Solaris [2], and Windows [3]. Note that the 
code under src/java.base/unix is built on all Unix systems including Linux, OS 
X, and Solaris. Secondly but of lesser note there were some warnings during the 
Linux build [4]. Otherwise the IO and NIO tests succeeded on Linux, but that 
only suggests that pre-existing functionality is preserved as those tests of 
course do not exercise the new code for which I suppose tests will be provided 
in the final version of the patch.

Regards,

Brian

[1] OS X

build/macosx-x64/support/gensrc/java.base/sun/nio/fs/UnixConstants.java:41: 
error: self-reference in initializer

static final int O_DIRECT = O_DIRECT;

^
[2] Solaris

build/solaris-x64/support/gensrc/java.base/sun/nio/fs/UnixConstants.java:41: 
error: self-reference in initializer

static final int O_DIRECT = O_DIRECT;

^
[3] Windows

jdk\src\java.base\windows\classes\java\io\FileDescriptor.java:76: error: 
 is not abstract and does not override 
abstract method getDirect(FileDescriptor) in JavaIOFileDescriptorAccess

new JavaIOFileDescriptorAccess() {

 ^
[4] Linux (Ubuntu 16.04 amd64 desktop)

jdk/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c: In function 
'readDirect':
jdk/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c:104:5: warning: 
ignoring return value of 'posix_memalign', declared with attribute 
warn_unused_result [-Wunused-result]
 posix_memalign(, pageSize, newLen);
 ^
jdk/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c: In function 
'writeDirect':
jdk/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c:131:5: warning: 
ignoring return value of 'posix_memalign', declared with attribute 
warn_unused_result [-Wunused-result]
 posix_memalign(, pageSize, len);
 ^
jdk/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c: In function 
'Java_sun_nio_ch_FileDispatcherImpl_readvDirect0':
jdk/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c:250:5: warning: 
ignoring return value of 'posix_memalign', declared with attribute 
warn_unused_result [-Wunused-result]
 posix_memalign(, pageSize, newLen);
 ^
jdk/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c: In function 
'Java_sun_nio_ch_FileDispatcherImpl_writevDirect0':
jdk/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c:393:5: warning: 
ignoring return value of 'posix_memalign', declared with attribute 
warn_unused_result [-Wunused-result]
 posix_memalign(, pageSize, totalLen)

Re: Proposal for adding O_DIRECT support into JDK 9

[Brian Burkhalter]

Hi Lucy,

On Oct 4, 2016, at 10:24 AM, Lu, Yingqi  wrote:

> Anyone else has any feedback/comments?


I looked over the 8164900-2 patch and did not see any conceptual problems per 
se. I did not however scrutinize all the detailed changes, especially the more 
extensive ones in FileDispatcherImpl.c. I did however run the patch through our 
regression tests for IO and NIO and encountered some problems. Firstly the 
patch breaks the build on OS X [1], Solaris [2], and Windows [3]. Note that the 
code under src/java.base/unix is built on all Unix systems including Linux, OS 
X, and Solaris. Secondly but of lesser note there were some warnings during the 
Linux build [4]. Otherwise the IO and NIO tests succeeded on Linux, but that 
only suggests that pre-existing functionality is preserved as those tests of 
course do not exercise the new code for which I suppose tests will be provided 
in the final version of the patch.

Regards,

Brian

[1] OS X
build/macosx-x64/support/gensrc/java.base/sun/nio/fs/UnixConstants.java:41: 
error: self-reference in initializer
static final int O_DIRECT = O_DIRECT;
^
[2] Solaris
build/solaris-x64/support/gensrc/java.base/sun/nio/fs/UnixConstants.java:41: 
error: self-reference in initializer
static final int O_DIRECT = O_DIRECT;
^
[3] Windows
jdk\src\java.base\windows\classes\java\io\FileDescriptor.java:76: error: 
 is not abstract and does not override 
abstract method getDirect(FileDescriptor) in JavaIOFileDescriptorAccess
new JavaIOFileDescriptorAccess() {
 ^
[4] Linux (Ubuntu 16.04 amd64 desktop)

jdk/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c: In function 
‘readDirect’:
jdk/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c:104:5: warning: 
ignoring return value of ‘posix_memalign’, declared with attribute 
warn_unused_result [-Wunused-result]
 posix_memalign(, pageSize, newLen);
 ^
jdk/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c: In function 
‘writeDirect’:
jdk/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c:131:5: warning: 
ignoring return value of ‘posix_memalign’, declared with attribute 
warn_unused_result [-Wunused-result]
 posix_memalign(, pageSize, len);
 ^
jdk/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c: In function 
‘Java_sun_nio_ch_FileDispatcherImpl_readvDirect0’:
jdk/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c:250:5: warning: 
ignoring return value of ‘posix_memalign’, declared with attribute 
warn_unused_result [-Wunused-result]
 posix_memalign(, pageSize, newLen);
 ^
jdk/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c: In function 
‘Java_sun_nio_ch_FileDispatcherImpl_writevDirect0’:
jdk/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c:393:5: warning: 
ignoring return value of ‘posix_memalign’, declared with attribute 
warn_unused_result [-Wunused-result]
 posix_memalign(, pageSize, totalLen)

RE: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

Hi Christoph,

Thank you very much for trying our patch. 

We are still seeking the feedback from the community. When we get closer to the 
final version of the patch, we will modify the copyright years. Thank you for 
reminding us!

Anyone else has any feedback/comments?

Thanks,
Lucy

-Original Message-
From: Langer, Christoph [mailto:christoph.lan...@sap.com] 
Sent: Tuesday, October 04, 2016 1:33 AM
To: Lu, Yingqi <yingqi...@intel.com>; Alan Bateman <alan.bate...@oracle.com>; 
core-libs-dev@openjdk.java.net
Cc: nio-...@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com>; 
Kharbas, Kishor <kishor.khar...@intel.com>
Subject: RE: Proposal for adding O_DIRECT support into JDK 9

Hi Lucy,

FWIW: I ran a build on AIX and this looks ok.

I also assume in your final version you'll update all copyright years where 
it's not 2016 yet? Other than that the changes look ok to me - but I'm neither 
a reviewer nor a deep expert in the area of your changes.

Best regards
Christoph

> -Original Message-
> From: nio-dev [mailto:nio-dev-boun...@openjdk.java.net] On Behalf Of 
> Lu, Yingqi
> Sent: Freitag, 30. September 2016 18:55
> To: Lu, Yingqi <yingqi...@intel.com>; Alan Bateman 
> <alan.bate...@oracle.com>; core-libs-dev@openjdk.java.net
> Cc: nio-...@openjdk.java.net; Kaczmarek, Eric 
> <eric.kaczma...@intel.com>; Kharbas, Kishor <kishor.khar...@intel.com>
> Subject: RE: Proposal for adding O_DIRECT support into JDK 9
> 
> Hi All,
> 
> Please find the most recent version of the patch available at 
> http://cr.openjdk.java.net/~igraves/8164900-2/
> 
> In this version, we have following two changes:
> 
> 1. Move O_DIRECT flag from StandardOpenOption to ExtendedOpenOption 2. 
> Move the checks of O_DIRECT from native code to Java code.
> 
> Please let us know your feedback.
> 
> Thanks,
> Lucy
> 
> -Original Message-
> From: nio-dev [mailto:nio-dev-boun...@openjdk.java.net] On Behalf Of 
> Lu, Yingqi
> Sent: Tuesday, September 27, 2016 9:57 AM
> To: Alan Bateman <alan.bate...@oracle.com>; core-libs- 
> d...@openjdk.java.net
> Cc: nio-...@openjdk.java.net
> Subject: RE: Proposal for adding O_DIRECT support into JDK 9
> 
> Alan,
> 
> Thank you for the explanation, we will modify the code accordingly and 
> send it out soon for review.
> 
> Thanks,
> Lucy
> 
> -Original Message-
> From: Alan Bateman [mailto:alan.bate...@oracle.com]
> Sent: Tuesday, September 27, 2016 8:45 AM
> To: Lu, Yingqi <yingqi...@intel.com>; core-libs-dev@openjdk.java.net
> Cc: nio-...@openjdk.java.net
> Subject: Re: Proposal for adding O_DIRECT support into JDK 9
> 
> On 26/09/2016 19:50, Lu, Yingqi wrote:
> 
> > Alan, you mean readv0/write0 or read0/write0? I just want to make 
> > sure
> > :-)
> Apologies, I meant each of the native methods where the decision to 
> use direct I/O or not would be a lot more maintainable in Java. You'll 
> see that there are already code paths for direct vs. heap buffers.
> 
> 
> >
> > Anyone else has other opinions on where is the best home for O_DIRECT flag?
> The flags under jdk.unsupported will eventually be removed in the 
> future JDK release?
> >
> > If we agree ExtendedOpenOpen is the best home for O_DIRECT, we can
> modify that for sure.
> >
> I think ExtendedOpenOption is the right place. It's still TDB as to 
> whether to put these extensions but that should be transparent to 
> anyone using this when on the class path.
> 
> -Alan

RE: Proposal for adding O_DIRECT support into JDK 9

[Langer, Christoph]

Hi Lucy,

FWIW: I ran a build on AIX and this looks ok.

I also assume in your final version you'll update all copyright years where 
it's not 2016 yet? Other than that the changes look ok to me - but I'm neither 
a reviewer nor a deep expert in the area of your changes.

Best regards
Christoph

> -Original Message-
> From: nio-dev [mailto:nio-dev-boun...@openjdk.java.net] On Behalf Of Lu,
> Yingqi
> Sent: Freitag, 30. September 2016 18:55
> To: Lu, Yingqi <yingqi...@intel.com>; Alan Bateman
> <alan.bate...@oracle.com>; core-libs-dev@openjdk.java.net
> Cc: nio-...@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com>;
> Kharbas, Kishor <kishor.khar...@intel.com>
> Subject: RE: Proposal for adding O_DIRECT support into JDK 9
> 
> Hi All,
> 
> Please find the most recent version of the patch available at
> http://cr.openjdk.java.net/~igraves/8164900-2/
> 
> In this version, we have following two changes:
> 
> 1. Move O_DIRECT flag from StandardOpenOption to ExtendedOpenOption
> 2. Move the checks of O_DIRECT from native code to Java code.
> 
> Please let us know your feedback.
> 
> Thanks,
> Lucy
> 
> -Original Message-
> From: nio-dev [mailto:nio-dev-boun...@openjdk.java.net] On Behalf Of Lu,
> Yingqi
> Sent: Tuesday, September 27, 2016 9:57 AM
> To: Alan Bateman <alan.bate...@oracle.com>; core-libs-
> d...@openjdk.java.net
> Cc: nio-...@openjdk.java.net
> Subject: RE: Proposal for adding O_DIRECT support into JDK 9
> 
> Alan,
> 
> Thank you for the explanation, we will modify the code accordingly and send it
> out soon for review.
> 
> Thanks,
> Lucy
> 
> -Original Message-
> From: Alan Bateman [mailto:alan.bate...@oracle.com]
> Sent: Tuesday, September 27, 2016 8:45 AM
> To: Lu, Yingqi <yingqi...@intel.com>; core-libs-dev@openjdk.java.net
> Cc: nio-...@openjdk.java.net
> Subject: Re: Proposal for adding O_DIRECT support into JDK 9
> 
> On 26/09/2016 19:50, Lu, Yingqi wrote:
> 
> > Alan, you mean readv0/write0 or read0/write0? I just want to make sure
> > :-)
> Apologies, I meant each of the native methods where the decision to use direct
> I/O or not would be a lot more maintainable in Java. You'll see that there are
> already code paths for direct vs. heap buffers.
> 
> 
> >
> > Anyone else has other opinions on where is the best home for O_DIRECT flag?
> The flags under jdk.unsupported will eventually be removed in the future JDK
> release?
> >
> > If we agree ExtendedOpenOpen is the best home for O_DIRECT, we can
> modify that for sure.
> >
> I think ExtendedOpenOption is the right place. It's still TDB as to whether 
> to put
> these extensions but that should be transparent to anyone using this when on
> the class path.
> 
> -Alan

RE: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

Hi All,

Please find the most recent version of the patch available at 
http://cr.openjdk.java.net/~igraves/8164900-2/

In this version, we have following two changes:

1. Move O_DIRECT flag from StandardOpenOption to ExtendedOpenOption
2. Move the checks of O_DIRECT from native code to Java code.

Please let us know your feedback.

Thanks,
Lucy

-Original Message-
From: nio-dev [mailto:nio-dev-boun...@openjdk.java.net] On Behalf Of Lu, Yingqi
Sent: Tuesday, September 27, 2016 9:57 AM
To: Alan Bateman <alan.bate...@oracle.com>; core-libs-dev@openjdk.java.net
Cc: nio-...@openjdk.java.net
Subject: RE: Proposal for adding O_DIRECT support into JDK 9

Alan,

Thank you for the explanation, we will modify the code accordingly and send it 
out soon for review.

Thanks,
Lucy

-Original Message-
From: Alan Bateman [mailto:alan.bate...@oracle.com] 
Sent: Tuesday, September 27, 2016 8:45 AM
To: Lu, Yingqi <yingqi...@intel.com>; core-libs-dev@openjdk.java.net
Cc: nio-...@openjdk.java.net
Subject: Re: Proposal for adding O_DIRECT support into JDK 9

On 26/09/2016 19:50, Lu, Yingqi wrote:

> Alan, you mean readv0/write0 or read0/write0? I just want to make sure 
> :-)
Apologies, I meant each of the native methods where the decision to use direct 
I/O or not would be a lot more maintainable in Java. You'll see that there are 
already code paths for direct vs. heap buffers.


>
> Anyone else has other opinions on where is the best home for O_DIRECT flag? 
> The flags under jdk.unsupported will eventually be removed in the future JDK 
> release?
>
> If we agree ExtendedOpenOpen is the best home for O_DIRECT, we can modify 
> that for sure.
>
I think ExtendedOpenOption is the right place. It's still TDB as to whether to 
put these extensions but that should be transparent to anyone using this when 
on the class path.

-Alan

RE: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

Alan,

Thank you for the explanation, we will modify the code accordingly and send it 
out soon for review.

Thanks,
Lucy

-Original Message-
From: Alan Bateman [mailto:alan.bate...@oracle.com] 
Sent: Tuesday, September 27, 2016 8:45 AM
To: Lu, Yingqi <yingqi...@intel.com>; core-libs-dev@openjdk.java.net
Cc: nio-...@openjdk.java.net
Subject: Re: Proposal for adding O_DIRECT support into JDK 9

On 26/09/2016 19:50, Lu, Yingqi wrote:

> Alan, you mean readv0/write0 or read0/write0? I just want to make sure 
> :-)
Apologies, I meant each of the native methods where the decision to use direct 
I/O or not would be a lot more maintainable in Java. You'll see that there are 
already code paths for direct vs. heap buffers.


>
> Anyone else has other opinions on where is the best home for O_DIRECT flag? 
> The flags under jdk.unsupported will eventually be removed in the future JDK 
> release?
>
> If we agree ExtendedOpenOpen is the best home for O_DIRECT, we can modify 
> that for sure.
>
I think ExtendedOpenOption is the right place. It's still TDB as to whether to 
put these extensions but that should be transparent to anyone using this when 
on the class path.

-Alan

Re: Proposal for adding O_DIRECT support into JDK 9

[Alan Bateman]

On 26/09/2016 19:50, Lu, Yingqi wrote:


Alan, you mean readv0/write0 or read0/write0? I just want to make sure :-)
Apologies, I meant each of the native methods where the decision to use 
direct I/O or not would be a lot more maintainable in Java. You'll see 
that there are already code paths for direct vs. heap buffers.





Anyone else has other opinions on where is the best home for O_DIRECT flag? The 
flags under jdk.unsupported will eventually be removed in the future JDK 
release?

If we agree ExtendedOpenOpen is the best home for O_DIRECT, we can modify that 
for sure.

I think ExtendedOpenOption is the right place. It's still TDB as to 
whether to put these extensions but that should be transparent to anyone 
using this when on the class path.


-Alan

RE: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

Alan, you mean readv0/write0 or read0/write0? I just want to make sure :-)

Anyone else has other opinions on where is the best home for O_DIRECT flag? The 
flags under jdk.unsupported will eventually be removed in the future JDK 
release?

If we agree ExtendedOpenOpen is the best home for O_DIRECT, we can modify that 
for sure.

Thanks,
Lucy

-Original Message-
From: Alan Bateman [mailto:alan.bate...@oracle.com] 
Sent: Monday, September 26, 2016 11:42 AM
To: Lu, Yingqi <yingqi...@intel.com>; core-libs-dev@openjdk.java.net
Cc: nio-...@openjdk.java.net
Subject: Re: Proposal for adding O_DIRECT support into JDK 9



On 26/09/2016 19:17, Lu, Yingqi wrote:
> Hi All,
>
> The second version of the patch is now available at 
> http://cr.openjdk.java.net/~igraves/8164900-1/. In this version, we moved the 
> O_DIRECT support from FIS/FOS/RAF to FileChannel. We implemented O_DIRECT as 
> a StandardOpenOption. The reason we did not make it as one of the 
> ExtendedOpenOptions is because we found ExtendedOpenOption is now moved to 
> jdk.unsupported. Please let us know if we misunderstood anything here. We can 
> modify it accordingly if there is a better place to put this flag.
ExtendedOpenOption seems the right place for this (we haven't found a good home 
for this yet).

I skimmed the implementation and the changes to readv0/write0 are a concern - I 
suspect you'll need to hoist the bulk of this into FileChannelImpl so that most 
of this native code can be eliminated.

-Alan

Re: Proposal for adding O_DIRECT support into JDK 9

[Alan Bateman]

On 26/09/2016 19:17, Lu, Yingqi wrote:

Hi All,

The second version of the patch is now available at 
http://cr.openjdk.java.net/~igraves/8164900-1/. In this version, we moved the 
O_DIRECT support from FIS/FOS/RAF to FileChannel. We implemented O_DIRECT as a 
StandardOpenOption. The reason we did not make it as one of the 
ExtendedOpenOptions is because we found ExtendedOpenOption is now moved to 
jdk.unsupported. Please let us know if we misunderstood anything here. We can 
modify it accordingly if there is a better place to put this flag.
ExtendedOpenOption seems the right place for this (we haven't found a 
good home for this yet).


I skimmed the implementation and the changes to readv0/write0 are a 
concern - I suspect you'll need to hoist the bulk of this into 
FileChannelImpl so that most of this native code can be eliminated.


-Alan

RE: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

Hi All,

The second version of the patch is now available at 
http://cr.openjdk.java.net/~igraves/8164900-1/. In this version, we moved the 
O_DIRECT support from FIS/FOS/RAF to FileChannel. We implemented O_DIRECT as a 
StandardOpenOption. The reason we did not make it as one of the 
ExtendedOpenOptions is because we found ExtendedOpenOption is now moved to 
jdk.unsupported. Please let us know if we misunderstood anything here. We can 
modify it accordingly if there is a better place to put this flag.

Please let us know your feedback and comments on the patch!

Thanks,
Lucy

-Original Message-
From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf 
Of Lu, Yingqi
Sent: Saturday, August 27, 2016 9:01 AM
To: Alan Bateman <alan.bate...@oracle.com>
Cc: core-libs-dev@openjdk.java.net; Kaczmarek, Eric <eric.kaczma...@intel.com>
Subject: Re: Proposal for adding O_DIRECT support into JDK 9

The workload we have uses fis/fos/raf, that is why we started here following 
the example of other file open flags. We can surely look into filechannel 
extended open options to see if it fits better there. 

Thanks,
Lucy

Sent from my iPhone

> On Aug 27, 2016, at 12:43 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
> 
>> On 26/08/2016 23:31, Lu, Yingqi wrote:
>> 
>> Dear All,
>> 
>> This is a proposal for adding O_DIRECT support into JDK 9 for 
>> reading/writing from/to a file on Linux platform. O_DIRECT is a file-open 
>> flag to pass to OPEN (2). It tries to minimize cache effects of the I/O to 
>> and from this file. File I/O is done directly to/from user-space buffers. 
>> Please refer to http://man7.org/linux/man-pages/man2/open.2.html for more 
>> details.
> FIS/FOS/RAF doesn't seem the right place for this. Have you looked at using 
> extended open options with FileChannel instead?
> 
> -Alan

RE: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

Hi Uwe/Andrew,

Thank you both for the suggestions. I agree it would be cleaner to make 
O_DIRECT an extended open options within nio package. 

We will modify the patch and update the community soon!

Thanks,
Lucy

-Original Message-
From: Uwe Schindler [mailto:uschind...@apache.org] 
Sent: Sunday, August 28, 2016 3:30 AM
To: 'Andrew Haley' <a...@redhat.com>; Lu, Yingqi <yingqi...@intel.com>; 
core-libs-dev@openjdk.java.net
Cc: Kaczmarek, Eric <eric.kaczma...@intel.com>
Subject: RE: Proposal for adding O_DIRECT support into JDK 9

Hi,

IMHO, I'd stay with FOS/FIS/RAF completely out of this business and not change 
them anymore. Those are legacy APIs!

I'd suggest to add this to StandardOpenOptions 
(https://docs.oracle.com/javase/8/docs/api/java/nio/file/StandardOpenOption.html)
 and use it solely with the Java 7+ NIO.2 Path APIs. No need to change the 
old-style java.io.File based APIs. This is easy to implement and add, because 
you would only add the new Enum constant and then implement it in the default 
FileSystem(-Provider) for each platform.

Uwe

-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer Bremen, Germany 
http://lucene.apache.org/

> -Original Message-
> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On 
> Behalf Of Andrew Haley
> Sent: Sunday, August 28, 2016 12:23 PM
> To: Lu, Yingqi <yingqi...@intel.com>; core-libs-dev@openjdk.java.net
> Cc: Kaczmarek, Eric <eric.kaczma...@intel.com>
> Subject: Re: Proposal for adding O_DIRECT support into JDK 9
> 
> On 26/08/16 23:31, Lu, Yingqi wrote:
> 
> > The proposal adds 4 API methods to java/io/FileInputStream.java, 
> > java/io/OutputStream.java to enable the feature. In addition, it add 
> > O_DIRECT with two more modes "ro" (read-only and direct) and "rwo"
> > (read-write and direct) to java/io/RandomAccessFile.java.
> >
> > public FileInputStream(String name, boolean direct) throws
> FileNotFoundException
> 
> Adding a boolean for O_DIRECT does not scale well.  There are many 
> other flags, and if there is some future expansion it would mean 
> adding more boolean arguments to the call signature.  It might be 
> worth considering a more direct way to make the call to open(2).  I 
> appreciate that not every flag passed to open() makes sense, though.
> And there is Windows etc. to think about.  But something like
> 
>   new FileInputStream(filename, File.DIRECT | File.APPEND)
> 
> is much more scalable and involves less argument marshalling.
> 
> Andrew.

RE: Proposal for adding O_DIRECT support into JDK 9

[Uwe Schindler]

Hi,

IMHO, I'd stay with FOS/FIS/RAF completely out of this business and not change 
them anymore. Those are legacy APIs!

I'd suggest to add this to StandardOpenOptions 
(https://docs.oracle.com/javase/8/docs/api/java/nio/file/StandardOpenOption.html)
 and use it solely with the Java 7+ NIO.2 Path APIs. No need to change the 
old-style java.io.File based APIs. This is easy to implement and add, because 
you would only add the new Enum constant and then implement it in the default 
FileSystem(-Provider) for each platform.

Uwe

-
Uwe Schindler
uschind...@apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/

> -Original Message-
> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
> Behalf Of Andrew Haley
> Sent: Sunday, August 28, 2016 12:23 PM
> To: Lu, Yingqi <yingqi...@intel.com>; core-libs-dev@openjdk.java.net
> Cc: Kaczmarek, Eric <eric.kaczma...@intel.com>
> Subject: Re: Proposal for adding O_DIRECT support into JDK 9
> 
> On 26/08/16 23:31, Lu, Yingqi wrote:
> 
> > The proposal adds 4 API methods to java/io/FileInputStream.java,
> > java/io/OutputStream.java to enable the feature. In addition, it add
> > O_DIRECT with two more modes "ro" (read-only and direct) and "rwo"
> > (read-write and direct) to java/io/RandomAccessFile.java.
> >
> > public FileInputStream(String name, boolean direct) throws
> FileNotFoundException
> 
> Adding a boolean for O_DIRECT does not scale well.  There are many
> other flags, and if there is some future expansion it would mean
> adding more boolean arguments to the call signature.  It might be
> worth considering a more direct way to make the call to open(2).  I
> appreciate that not every flag passed to open() makes sense, though.
> And there is Windows etc. to think about.  But something like
> 
>   new FileInputStream(filename, File.DIRECT | File.APPEND)
> 
> is much more scalable and involves less argument marshalling.
> 
> Andrew.

Re: Proposal for adding O_DIRECT support into JDK 9

[Andrew Haley]

On 26/08/16 23:31, Lu, Yingqi wrote:

> The proposal adds 4 API methods to java/io/FileInputStream.java,
> java/io/OutputStream.java to enable the feature. In addition, it add
> O_DIRECT with two more modes "ro" (read-only and direct) and "rwo"
> (read-write and direct) to java/io/RandomAccessFile.java.
> 
> public FileInputStream(String name, boolean direct) throws 
> FileNotFoundException

Adding a boolean for O_DIRECT does not scale well.  There are many
other flags, and if there is some future expansion it would mean
adding more boolean arguments to the call signature.  It might be
worth considering a more direct way to make the call to open(2).  I
appreciate that not every flag passed to open() makes sense, though.
And there is Windows etc. to think about.  But something like

  new FileInputStream(filename, File.DIRECT | File.APPEND)

is much more scalable and involves less argument marshalling.

Andrew.

Re: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

The workload we have uses fis/fos/raf, that is why we started here following 
the example of other file open flags. We can surely look into filechannel 
extended open options to see if it fits better there. 

Thanks,
Lucy

Sent from my iPhone

> On Aug 27, 2016, at 12:43 AM, Alan Bateman  wrote:
> 
>> On 26/08/2016 23:31, Lu, Yingqi wrote:
>> 
>> Dear All,
>> 
>> This is a proposal for adding O_DIRECT support into JDK 9 for 
>> reading/writing from/to a file on Linux platform. O_DIRECT is a file-open 
>> flag to pass to OPEN (2). It tries to minimize cache effects of the I/O to 
>> and from this file. File I/O is done directly to/from user-space buffers. 
>> Please refer to http://man7.org/linux/man-pages/man2/open.2.html for more 
>> details.
> FIS/FOS/RAF doesn't seem the right place for this. Have you looked at using 
> extended open options with FileChannel instead?
> 
> -Alan

Re: Proposal for adding O_DIRECT support into JDK 9

[Alan Bateman]

On 26/08/2016 23:31, Lu, Yingqi wrote:


Dear All,

This is a proposal for adding O_DIRECT support into JDK 9 for reading/writing 
from/to a file on Linux platform. O_DIRECT is a file-open flag to pass to OPEN 
(2). It tries to minimize cache effects of the I/O to and from this file. File 
I/O is done directly to/from user-space buffers. Please refer to 
http://man7.org/linux/man-pages/man2/open.2.html for more details.


FIS/FOS/RAF doesn't seem the right place for this. Have you looked at 
using extended open options with FileChannel instead?


-Alan