Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8259034

PANAMA: MemorySegment#mapFile should alternatively take FileChannel instead of Path

XMLWordPrintable

    • generic
    • generic

      This is a suggestion for an improvement, so priority is not too high, but especially for Windows this is a huge performance problem:

      With MappedByteBuffer, you can create the mmap mapping using an instance of FileChannel (using FileChannel#map). This allows to create multiple mappings per file in a very convenient way (e.g., to use slices instead of a huge mapping to prevent address space exhaustion). The code in MemorySegment only takes a Path and creates the FileChannel on its own. When you create many mappings on the same file, the number of syscalls to open/close/read file size takes a lot of time, especially on windows. In addition, you cannot create the mappings in some "atomic" way (of course you can lock file, but the whole thing is very risky if e.g. file size changes in meantime. With a single filechannel, you know that all sizes are consistent throughout the mappings).

      As MappedMemorySegmentimpl creates the file channel anyways, it might be a good idea to also expose a method that takes the FileChannel to create the mappings and make the Path method only as convenience.

      At a later stage when project Panama gets migrated into java.base I would really appreciate to have the possibility to map inside FileChannel! This would also help to prevent issues like JDK-8259028, as you have the control over the FileChannel you pass, e.g. if you have wrapped file systems.

            uschindler Uwe Schindler
            uschindler Uwe Schindler
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: