-
Bug
-
Resolution: Fixed
-
P2
-
16
-
b32
-
x86_64
-
windows_10
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8259421 | 17 | Maurizio Cimadamore | P2 | Resolved | Fixed | b05 |
JDK-8260104 | 16.0.1 | Maurizio Cimadamore | P2 | Resolved | Fixed | b03 |
At least on my computer (Windows), when passing a small offset to MemorySegment.mapFile(), the returned segment has the same contents with and without the offset. I tested this on my computer with a bytesOffset into the file of 64.
The reason for this is that on certain platform memory mapping of files with an offset is rounded down to some alignment (instead of mmap to file offset 64, it mmaps to offset 0 of file). To me this looks like the file system block size or similar (have not checked the native code).
The information about the address and also the pagePosition is saved inside the Unmapper object (exported as UnmapperProxy interface to foreign module). Unfortunately, UnmapperProxy, does not return address+pagePosition in its address() method, so the memory segment then always starts at the next block boundary instead of the real position in the file.
The classical FileChannel#map() method uses address+pagePosition in its code:
return Util.newMappedByteBufferR((int)unmapper.cap,
unmapper.address + unmapper.pagePosition,
unmapper.fd,
unmapper, isSync);
It would really be good to fix this bug as soon as possible in panama, because this prevents us from mapping portions of a file correctly!
I implemented some hacky workaround by applying the alignment on my own, but I can only do this as best guess (64 KiB alignment on Windows, 4 KiB alignment on Linux).
The reason for this is that on certain platform memory mapping of files with an offset is rounded down to some alignment (instead of mmap to file offset 64, it mmaps to offset 0 of file). To me this looks like the file system block size or similar (have not checked the native code).
The information about the address and also the pagePosition is saved inside the Unmapper object (exported as UnmapperProxy interface to foreign module). Unfortunately, UnmapperProxy, does not return address+pagePosition in its address() method, so the memory segment then always starts at the next block boundary instead of the real position in the file.
The classical FileChannel#map() method uses address+pagePosition in its code:
return Util.newMappedByteBufferR((int)unmapper.cap,
unmapper.address + unmapper.pagePosition,
unmapper.fd,
unmapper, isSync);
It would really be good to fix this bug as soon as possible in panama, because this prevents us from mapping portions of a file correctly!
I implemented some hacky workaround by applying the alignment on my own, but I can only do this as best guess (64 KiB alignment on Windows, 4 KiB alignment on Linux).
- backported by
-
JDK-8259421 MappedMemorySegmentImpl#makeMappedSegment() ignores Unmapper#pagePosition
- Resolved
-
JDK-8260104 MappedMemorySegmentImpl#makeMappedSegment() ignores Unmapper#pagePosition
- Resolved