Package org.lwjgl.system.linux

Class MMAN

java.lang.Object
org.lwjgl.system.linux.MMAN
public class MMAN extends Object
Native bindings to <sys/mman.h>.

  • Field Summary

    Fields
    Modifier and Type
    Field
    Description
    static final int
    MAP_32BIT
    Enum values:
    static final int
    MAP_ANON
    Enum values:
    static final int
    MAP_ANONYMOUS
    Enum values:
    static final int
    MAP_DENYWRITE
    Enum values:
    static final int
    MAP_EXECUTABLE
    Enum values:
    static final long
    MAP_FAILED
    Return value of mmap(java.nio.IntBuffer, long, long, int, int, int, long) in case of an error.
    static final int
    MAP_FILE
    Enum values:
    static final int
    MAP_FIXED
    Enum values:
    static final int
    MAP_FIXED_NOREPLACE
    Enum values:
    static final int
    MAP_GROWSDOWN
    Enum values:
    static final int
    MAP_HUGE_1GB
    Enum values:
    static final int
    MAP_HUGE_2MB
    Enum values:
    static final int
    MAP_HUGE_MASK
     
    static final int
    MAP_HUGE_SHIFT
     
    static final int
    MAP_HUGETLB
    Enum values:
    static final int
    MAP_LOCKED
    Enum values:
    static final int
    MAP_NONBLOCK
    Enum values:
    static final int
    MAP_NORESERVE
    Enum values:
    static final int
    MAP_POPULATE
    Enum values:
    static final int
    MAP_PRIVATE
    The flags argument determines whether updates to the mapping are visible to other processes mapping the same region, and whether updates are carried through to the underlying file.
    static final int
    MAP_SHARED
    The flags argument determines whether updates to the mapping are visible to other processes mapping the same region, and whether updates are carried through to the underlying file.
    static final int
    MAP_SHARED_VALIDATE
    The flags argument determines whether updates to the mapping are visible to other processes mapping the same region, and whether updates are carried through to the underlying file.
    static final int
    MAP_STACK
    Enum values:
    static final int
    MAP_SYNC
    Enum values:
    static final int
    MAP_UNINITIALIZED
    Enum values:
    static final int
    PROT_EXEC
    The prot argument describes the desired memory protection of the mapping (and must not conflict with the open mode of the file).
    static final int
    PROT_GROWSDOWN
    The prot argument describes the desired memory protection of the mapping (and must not conflict with the open mode of the file).
    static final int
    PROT_GROWSUP
    The prot argument describes the desired memory protection of the mapping (and must not conflict with the open mode of the file).
    static final int
    PROT_NONE
    The prot argument describes the desired memory protection of the mapping (and must not conflict with the open mode of the file).
    static final int
    PROT_READ
    The prot argument describes the desired memory protection of the mapping (and must not conflict with the open mode of the file).
    static final int
    PROT_WRITE
    The prot argument describes the desired memory protection of the mapping (and must not conflict with the open mode of the file).

  • Method Summary

    Modifier and Type
    Method
    Description
    static long
    mmap(@Nullable IntBuffer _errno, long addr, long length, int prot, int flags, int fd, long offset)
    Creates a new mapping in the virtual address space of the calling process.
    static int
    munmap(@Nullable IntBuffer _errno, ByteBuffer addr)
    Deletes the mappings for the specified address range, and causes further references to addresses within the range to generate invalid memory references.
    static long
    nmmap(long _errno, long addr, long length, int prot, int flags, int fd, long offset)
    Unsafe version of: mmap(java.nio.IntBuffer, long, long, int, int, int, long)
    static int
    nmunmap(long _errno, long addr, long length)
    Unsafe version of: munmap(java.nio.IntBuffer, java.nio.ByteBuffer)

    Methods inherited from class java.lang.Object

    equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

  • Field Details

    • MAP_FAILED

      public static final long MAP_FAILED
      Return value of mmap(java.nio.IntBuffer, long, long, int, int, int, long) in case of an error.
      See Also:

    • PROT_EXEC

      public static final int PROT_EXEC
      The prot argument describes the desired memory protection of the mapping (and must not conflict with the open mode of the file).

      It is either PROT_NONE or the bitwise OR of one or more of the following flags.

      Enum values:
      See Also:

    • PROT_READ

      public static final int PROT_READ
      The prot argument describes the desired memory protection of the mapping (and must not conflict with the open mode of the file).

      It is either PROT_NONE or the bitwise OR of one or more of the following flags.

      Enum values:
      See Also:

    • PROT_WRITE

      public static final int PROT_WRITE
      The prot argument describes the desired memory protection of the mapping (and must not conflict with the open mode of the file).

      It is either PROT_NONE or the bitwise OR of one or more of the following flags.

      Enum values:
      See Also:

    • PROT_NONE

      public static final int PROT_NONE
      The prot argument describes the desired memory protection of the mapping (and must not conflict with the open mode of the file).

      It is either PROT_NONE or the bitwise OR of one or more of the following flags.

      Enum values:
      See Also:

    • PROT_GROWSDOWN

      public static final int PROT_GROWSDOWN
      The prot argument describes the desired memory protection of the mapping (and must not conflict with the open mode of the file).

      It is either PROT_NONE or the bitwise OR of one or more of the following flags.

      Enum values:
      See Also:

    • PROT_GROWSUP

      public static final int PROT_GROWSUP
      The prot argument describes the desired memory protection of the mapping (and must not conflict with the open mode of the file).

      It is either PROT_NONE or the bitwise OR of one or more of the following flags.

      Enum values:
      See Also:

    • MAP_SHARED

      public static final int MAP_SHARED
      The flags argument determines whether updates to the mapping are visible to other processes mapping the same region, and whether updates are carried through to the underlying file.

      This behavior is determined by including exactly one of the following values in flags.

      Enum values:
      • MAP_SHARED - Share this mapping.

        Updates to the mapping are visible to other processes mapping the same region, and (in the case of file-backed mappings) are carried through to the underlying file. (To precisely control when updates are carried through to the underlying file requires the use of msync(2).)

      • MAP_SHARED_VALIDATE - This flag provides the same behavior as MAP_SHARED except that MAP_SHARED mappings ignore unknown flags in flags.

        By contrast, when creating a mapping using MAP_SHARED_VALIDATE, the kernel verifies all passed flags are known and fails the mapping with the error EOPNOTSUPP for unknown flags. This mapping type is also required to be able to use some mapping flags (e.g., MAP_SYNC).

      • MAP_PRIVATE - Create a private copy-on-write mapping.

        Updates to the mapping are not visible to other processes mapping the same file, and are not carried through to the underlying file. It is unspecified whether changes made to the file after the mmap(java.nio.IntBuffer, long, long, int, int, int, long) call are visible in the mapped region.

      See Also:

    • MAP_SHARED_VALIDATE

      public static final int MAP_SHARED_VALIDATE
      The flags argument determines whether updates to the mapping are visible to other processes mapping the same region, and whether updates are carried through to the underlying file.

      This behavior is determined by including exactly one of the following values in flags.

      Enum values:
      • MAP_SHARED - Share this mapping.

        Updates to the mapping are visible to other processes mapping the same region, and (in the case of file-backed mappings) are carried through to the underlying file. (To precisely control when updates are carried through to the underlying file requires the use of msync(2).)

      • MAP_SHARED_VALIDATE - This flag provides the same behavior as MAP_SHARED except that MAP_SHARED mappings ignore unknown flags in flags.

        By contrast, when creating a mapping using MAP_SHARED_VALIDATE, the kernel verifies all passed flags are known and fails the mapping with the error EOPNOTSUPP for unknown flags. This mapping type is also required to be able to use some mapping flags (e.g., MAP_SYNC).

      • MAP_PRIVATE - Create a private copy-on-write mapping.

        Updates to the mapping are not visible to other processes mapping the same file, and are not carried through to the underlying file. It is unspecified whether changes made to the file after the mmap(java.nio.IntBuffer, long, long, int, int, int, long) call are visible in the mapped region.

      See Also:

    • MAP_PRIVATE

      public static final int MAP_PRIVATE
      The flags argument determines whether updates to the mapping are visible to other processes mapping the same region, and whether updates are carried through to the underlying file.

      This behavior is determined by including exactly one of the following values in flags.

      Enum values:
      • MAP_SHARED - Share this mapping.

        Updates to the mapping are visible to other processes mapping the same region, and (in the case of file-backed mappings) are carried through to the underlying file. (To precisely control when updates are carried through to the underlying file requires the use of msync(2).)

      • MAP_SHARED_VALIDATE - This flag provides the same behavior as MAP_SHARED except that MAP_SHARED mappings ignore unknown flags in flags.

        By contrast, when creating a mapping using MAP_SHARED_VALIDATE, the kernel verifies all passed flags are known and fails the mapping with the error EOPNOTSUPP for unknown flags. This mapping type is also required to be able to use some mapping flags (e.g., MAP_SYNC).

      • MAP_PRIVATE - Create a private copy-on-write mapping.

        Updates to the mapping are not visible to other processes mapping the same file, and are not carried through to the underlying file. It is unspecified whether changes made to the file after the mmap(java.nio.IntBuffer, long, long, int, int, int, long) call are visible in the mapped region.

      See Also:

    • MAP_HUGE_SHIFT

      public static final int MAP_HUGE_SHIFT
      See Also:

    • MAP_HUGE_MASK

      public static final int MAP_HUGE_MASK
      See Also:

    • MAP_32BIT

      public static final int MAP_32BIT
      Enum values:
      • MAP_32BIT - Put the mapping into the first 2 Gigabytes of the process address space.

        This flag is supported only on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2 GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance problem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set.

      • MAP_ANONYMOUS - The mapping is not backed by any file; its contents are initialized to zero.

        The fd argument is ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The offset argument should be zero. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is supported on Linux only since kernel 2.4.

      • MAP_ANON - Synonym for MAP_ANONYMOUS; provided for compatibility with other implementations.
      • MAP_DENYWRITE - This flag is ignored.

        (Long ago —Linux 2.0 and earlier— it signaled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial-of-service attacks.)

      • MAP_EXECUTABLE - This flag is ignored.
      • MAP_FILE - Compatibility flag. Ignored.
      • MAP_FIXED - Don't interpret addr as a hint: place the mapping at exactly that address.

        addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions. If the memory region specified by addr and length overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap(java.nio.IntBuffer, long, long, int, int, int, long) will fail.

        Software that aspires to be portable should use the MAP_FIXED flag with care, keeping in mind that the exact layout of a process's memory mappings is allowed to change significantly between kernel versions, C library versions, and operating system releases. Carefully read the discussion of this flag in NOTES!

      • MAP_FIXED_NOREPLACE - This flag provides behavior that is similar to MAP_FIXED with respect to the addr enforcement, but differs in that MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.

        If the requested range would collide with an existing mapping, then this call fails with the error EEXIST. This flag can therefore be used as a way to atomically (with respect to other threads) attempt to map an address range: one thread will succeed; all others will report failure.

        Note that older kernels which do not recognize the MAP_FIXED_NOREPLACE flag will typically (upon detecting a collision with a preexisting mapping) fall back to a "non-MAP_FIXED" type of behavior: they will return an address that is different from the requested address. Therefore, backward-compatible software should check the returned address against the requested address.

        (since Linux 4.17)

      • MAP_GROWSDOWN - This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory.

        The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page. This growth can be repeated until the mapping grows to within a page of the high end of the next lower mapping, at which point touching the "guard" page will result in a SIGSEGV signal.

      • MAP_HUGETLB - Allocate the mapping using "huge" pages.

        See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst for further information, as well as NOTES, below.

        (since Linux 2.6.32)

      • MAP_HUGE_2MB - Used in conjunction with MAP_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

        More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset MAP_HUGE_SHIFT. (A value of zero in this bit field provides the default huge page size; the default huge page size can be discovered via the Hugepagesize field exposed by /proc/meminfo.) Thus, the above two constants are defined as:

        
 #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
 #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)

        The range of huge page sizes that are supported by the system can be discovered by listing the subdirectories in /sys/kernel/mm/hugepages.

        (since Linux 3.8)

      • MAP_HUGE_1GB - See MAP_HUGE_2MB.
      • MAP_LOCKED -
      • MAP_NONBLOCK -
      • MAP_NORESERVE -
      • MAP_POPULATE -
      • MAP_STACK -
      • MAP_SYNC -
      • MAP_UNINITIALIZED -
      See Also:

    • MAP_ANONYMOUS

      public static final int MAP_ANONYMOUS
      Enum values:
      • MAP_32BIT - Put the mapping into the first 2 Gigabytes of the process address space.

        This flag is supported only on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2 GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance problem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set.

      • MAP_ANONYMOUS - The mapping is not backed by any file; its contents are initialized to zero.

        The fd argument is ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The offset argument should be zero. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is supported on Linux only since kernel 2.4.

      • MAP_ANON - Synonym for MAP_ANONYMOUS; provided for compatibility with other implementations.
      • MAP_DENYWRITE - This flag is ignored.

        (Long ago —Linux 2.0 and earlier— it signaled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial-of-service attacks.)

      • MAP_EXECUTABLE - This flag is ignored.
      • MAP_FILE - Compatibility flag. Ignored.
      • MAP_FIXED - Don't interpret addr as a hint: place the mapping at exactly that address.

        addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions. If the memory region specified by addr and length overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap(java.nio.IntBuffer, long, long, int, int, int, long) will fail.

        Software that aspires to be portable should use the MAP_FIXED flag with care, keeping in mind that the exact layout of a process's memory mappings is allowed to change significantly between kernel versions, C library versions, and operating system releases. Carefully read the discussion of this flag in NOTES!

      • MAP_FIXED_NOREPLACE - This flag provides behavior that is similar to MAP_FIXED with respect to the addr enforcement, but differs in that MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.

        If the requested range would collide with an existing mapping, then this call fails with the error EEXIST. This flag can therefore be used as a way to atomically (with respect to other threads) attempt to map an address range: one thread will succeed; all others will report failure.

        Note that older kernels which do not recognize the MAP_FIXED_NOREPLACE flag will typically (upon detecting a collision with a preexisting mapping) fall back to a "non-MAP_FIXED" type of behavior: they will return an address that is different from the requested address. Therefore, backward-compatible software should check the returned address against the requested address.

        (since Linux 4.17)

      • MAP_GROWSDOWN - This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory.

        The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page. This growth can be repeated until the mapping grows to within a page of the high end of the next lower mapping, at which point touching the "guard" page will result in a SIGSEGV signal.

      • MAP_HUGETLB - Allocate the mapping using "huge" pages.

        See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst for further information, as well as NOTES, below.

        (since Linux 2.6.32)

      • MAP_HUGE_2MB - Used in conjunction with MAP_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

        More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset MAP_HUGE_SHIFT. (A value of zero in this bit field provides the default huge page size; the default huge page size can be discovered via the Hugepagesize field exposed by /proc/meminfo.) Thus, the above two constants are defined as:

        
 #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
 #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)

        The range of huge page sizes that are supported by the system can be discovered by listing the subdirectories in /sys/kernel/mm/hugepages.

        (since Linux 3.8)

      • MAP_HUGE_1GB - See MAP_HUGE_2MB.
      • MAP_LOCKED -
      • MAP_NONBLOCK -
      • MAP_NORESERVE -
      • MAP_POPULATE -
      • MAP_STACK -
      • MAP_SYNC -
      • MAP_UNINITIALIZED -
      See Also:

    • MAP_ANON

      public static final int MAP_ANON
      Enum values:
      • MAP_32BIT - Put the mapping into the first 2 Gigabytes of the process address space.

        This flag is supported only on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2 GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance problem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set.

      • MAP_ANONYMOUS - The mapping is not backed by any file; its contents are initialized to zero.

        The fd argument is ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The offset argument should be zero. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is supported on Linux only since kernel 2.4.

      • MAP_ANON - Synonym for MAP_ANONYMOUS; provided for compatibility with other implementations.
      • MAP_DENYWRITE - This flag is ignored.

        (Long ago —Linux 2.0 and earlier— it signaled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial-of-service attacks.)

      • MAP_EXECUTABLE - This flag is ignored.
      • MAP_FILE - Compatibility flag. Ignored.
      • MAP_FIXED - Don't interpret addr as a hint: place the mapping at exactly that address.

        addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions. If the memory region specified by addr and length overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap(java.nio.IntBuffer, long, long, int, int, int, long) will fail.

        Software that aspires to be portable should use the MAP_FIXED flag with care, keeping in mind that the exact layout of a process's memory mappings is allowed to change significantly between kernel versions, C library versions, and operating system releases. Carefully read the discussion of this flag in NOTES!

      • MAP_FIXED_NOREPLACE - This flag provides behavior that is similar to MAP_FIXED with respect to the addr enforcement, but differs in that MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.

        If the requested range would collide with an existing mapping, then this call fails with the error EEXIST. This flag can therefore be used as a way to atomically (with respect to other threads) attempt to map an address range: one thread will succeed; all others will report failure.

        Note that older kernels which do not recognize the MAP_FIXED_NOREPLACE flag will typically (upon detecting a collision with a preexisting mapping) fall back to a "non-MAP_FIXED" type of behavior: they will return an address that is different from the requested address. Therefore, backward-compatible software should check the returned address against the requested address.

        (since Linux 4.17)

      • MAP_GROWSDOWN - This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory.

        The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page. This growth can be repeated until the mapping grows to within a page of the high end of the next lower mapping, at which point touching the "guard" page will result in a SIGSEGV signal.

      • MAP_HUGETLB - Allocate the mapping using "huge" pages.

        See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst for further information, as well as NOTES, below.

        (since Linux 2.6.32)

      • MAP_HUGE_2MB - Used in conjunction with MAP_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

        More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset MAP_HUGE_SHIFT. (A value of zero in this bit field provides the default huge page size; the default huge page size can be discovered via the Hugepagesize field exposed by /proc/meminfo.) Thus, the above two constants are defined as:

        
 #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
 #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)

        The range of huge page sizes that are supported by the system can be discovered by listing the subdirectories in /sys/kernel/mm/hugepages.

        (since Linux 3.8)

      • MAP_HUGE_1GB - See MAP_HUGE_2MB.
      • MAP_LOCKED -
      • MAP_NONBLOCK -
      • MAP_NORESERVE -
      • MAP_POPULATE -
      • MAP_STACK -
      • MAP_SYNC -
      • MAP_UNINITIALIZED -
      See Also:

    • MAP_DENYWRITE

      public static final int MAP_DENYWRITE
      Enum values:
      • MAP_32BIT - Put the mapping into the first 2 Gigabytes of the process address space.

        This flag is supported only on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2 GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance problem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set.

      • MAP_ANONYMOUS - The mapping is not backed by any file; its contents are initialized to zero.

        The fd argument is ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The offset argument should be zero. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is supported on Linux only since kernel 2.4.

      • MAP_ANON - Synonym for MAP_ANONYMOUS; provided for compatibility with other implementations.
      • MAP_DENYWRITE - This flag is ignored.

        (Long ago —Linux 2.0 and earlier— it signaled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial-of-service attacks.)

      • MAP_EXECUTABLE - This flag is ignored.
      • MAP_FILE - Compatibility flag. Ignored.
      • MAP_FIXED - Don't interpret addr as a hint: place the mapping at exactly that address.

        addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions. If the memory region specified by addr and length overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap(java.nio.IntBuffer, long, long, int, int, int, long) will fail.

        Software that aspires to be portable should use the MAP_FIXED flag with care, keeping in mind that the exact layout of a process's memory mappings is allowed to change significantly between kernel versions, C library versions, and operating system releases. Carefully read the discussion of this flag in NOTES!

      • MAP_FIXED_NOREPLACE - This flag provides behavior that is similar to MAP_FIXED with respect to the addr enforcement, but differs in that MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.

        If the requested range would collide with an existing mapping, then this call fails with the error EEXIST. This flag can therefore be used as a way to atomically (with respect to other threads) attempt to map an address range: one thread will succeed; all others will report failure.

        Note that older kernels which do not recognize the MAP_FIXED_NOREPLACE flag will typically (upon detecting a collision with a preexisting mapping) fall back to a "non-MAP_FIXED" type of behavior: they will return an address that is different from the requested address. Therefore, backward-compatible software should check the returned address against the requested address.

        (since Linux 4.17)

      • MAP_GROWSDOWN - This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory.

        The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page. This growth can be repeated until the mapping grows to within a page of the high end of the next lower mapping, at which point touching the "guard" page will result in a SIGSEGV signal.

      • MAP_HUGETLB - Allocate the mapping using "huge" pages.

        See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst for further information, as well as NOTES, below.

        (since Linux 2.6.32)

      • MAP_HUGE_2MB - Used in conjunction with MAP_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

        More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset MAP_HUGE_SHIFT. (A value of zero in this bit field provides the default huge page size; the default huge page size can be discovered via the Hugepagesize field exposed by /proc/meminfo.) Thus, the above two constants are defined as:

        
 #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
 #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)

        The range of huge page sizes that are supported by the system can be discovered by listing the subdirectories in /sys/kernel/mm/hugepages.

        (since Linux 3.8)

      • MAP_HUGE_1GB - See MAP_HUGE_2MB.
      • MAP_LOCKED -
      • MAP_NONBLOCK -
      • MAP_NORESERVE -
      • MAP_POPULATE -
      • MAP_STACK -
      • MAP_SYNC -
      • MAP_UNINITIALIZED -
      See Also:

    • MAP_EXECUTABLE

      public static final int MAP_EXECUTABLE
      Enum values:
      • MAP_32BIT - Put the mapping into the first 2 Gigabytes of the process address space.

        This flag is supported only on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2 GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance problem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set.

      • MAP_ANONYMOUS - The mapping is not backed by any file; its contents are initialized to zero.

        The fd argument is ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The offset argument should be zero. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is supported on Linux only since kernel 2.4.

      • MAP_ANON - Synonym for MAP_ANONYMOUS; provided for compatibility with other implementations.
      • MAP_DENYWRITE - This flag is ignored.

        (Long ago —Linux 2.0 and earlier— it signaled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial-of-service attacks.)

      • MAP_EXECUTABLE - This flag is ignored.
      • MAP_FILE - Compatibility flag. Ignored.
      • MAP_FIXED - Don't interpret addr as a hint: place the mapping at exactly that address.

        addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions. If the memory region specified by addr and length overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap(java.nio.IntBuffer, long, long, int, int, int, long) will fail.

        Software that aspires to be portable should use the MAP_FIXED flag with care, keeping in mind that the exact layout of a process's memory mappings is allowed to change significantly between kernel versions, C library versions, and operating system releases. Carefully read the discussion of this flag in NOTES!

      • MAP_FIXED_NOREPLACE - This flag provides behavior that is similar to MAP_FIXED with respect to the addr enforcement, but differs in that MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.

        If the requested range would collide with an existing mapping, then this call fails with the error EEXIST. This flag can therefore be used as a way to atomically (with respect to other threads) attempt to map an address range: one thread will succeed; all others will report failure.

        Note that older kernels which do not recognize the MAP_FIXED_NOREPLACE flag will typically (upon detecting a collision with a preexisting mapping) fall back to a "non-MAP_FIXED" type of behavior: they will return an address that is different from the requested address. Therefore, backward-compatible software should check the returned address against the requested address.

        (since Linux 4.17)

      • MAP_GROWSDOWN - This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory.

        The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page. This growth can be repeated until the mapping grows to within a page of the high end of the next lower mapping, at which point touching the "guard" page will result in a SIGSEGV signal.

      • MAP_HUGETLB - Allocate the mapping using "huge" pages.

        See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst for further information, as well as NOTES, below.

        (since Linux 2.6.32)

      • MAP_HUGE_2MB - Used in conjunction with MAP_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

        More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset MAP_HUGE_SHIFT. (A value of zero in this bit field provides the default huge page size; the default huge page size can be discovered via the Hugepagesize field exposed by /proc/meminfo.) Thus, the above two constants are defined as:

        
 #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
 #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)

        The range of huge page sizes that are supported by the system can be discovered by listing the subdirectories in /sys/kernel/mm/hugepages.

        (since Linux 3.8)

      • MAP_HUGE_1GB - See MAP_HUGE_2MB.
      • MAP_LOCKED -
      • MAP_NONBLOCK -
      • MAP_NORESERVE -
      • MAP_POPULATE -
      • MAP_STACK -
      • MAP_SYNC -
      • MAP_UNINITIALIZED -
      See Also:

    • MAP_FILE

      public static final int MAP_FILE
      Enum values:
      • MAP_32BIT - Put the mapping into the first 2 Gigabytes of the process address space.

        This flag is supported only on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2 GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance problem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set.

      • MAP_ANONYMOUS - The mapping is not backed by any file; its contents are initialized to zero.

        The fd argument is ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The offset argument should be zero. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is supported on Linux only since kernel 2.4.

      • MAP_ANON - Synonym for MAP_ANONYMOUS; provided for compatibility with other implementations.
      • MAP_DENYWRITE - This flag is ignored.

        (Long ago —Linux 2.0 and earlier— it signaled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial-of-service attacks.)

      • MAP_EXECUTABLE - This flag is ignored.
      • MAP_FILE - Compatibility flag. Ignored.
      • MAP_FIXED - Don't interpret addr as a hint: place the mapping at exactly that address.

        addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions. If the memory region specified by addr and length overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap(java.nio.IntBuffer, long, long, int, int, int, long) will fail.

        Software that aspires to be portable should use the MAP_FIXED flag with care, keeping in mind that the exact layout of a process's memory mappings is allowed to change significantly between kernel versions, C library versions, and operating system releases. Carefully read the discussion of this flag in NOTES!

      • MAP_FIXED_NOREPLACE - This flag provides behavior that is similar to MAP_FIXED with respect to the addr enforcement, but differs in that MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.

        If the requested range would collide with an existing mapping, then this call fails with the error EEXIST. This flag can therefore be used as a way to atomically (with respect to other threads) attempt to map an address range: one thread will succeed; all others will report failure.

        Note that older kernels which do not recognize the MAP_FIXED_NOREPLACE flag will typically (upon detecting a collision with a preexisting mapping) fall back to a "non-MAP_FIXED" type of behavior: they will return an address that is different from the requested address. Therefore, backward-compatible software should check the returned address against the requested address.

        (since Linux 4.17)

      • MAP_GROWSDOWN - This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory.

        The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page. This growth can be repeated until the mapping grows to within a page of the high end of the next lower mapping, at which point touching the "guard" page will result in a SIGSEGV signal.

      • MAP_HUGETLB - Allocate the mapping using "huge" pages.

        See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst for further information, as well as NOTES, below.

        (since Linux 2.6.32)

      • MAP_HUGE_2MB - Used in conjunction with MAP_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

        More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset MAP_HUGE_SHIFT. (A value of zero in this bit field provides the default huge page size; the default huge page size can be discovered via the Hugepagesize field exposed by /proc/meminfo.) Thus, the above two constants are defined as:

        
 #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
 #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)

        The range of huge page sizes that are supported by the system can be discovered by listing the subdirectories in /sys/kernel/mm/hugepages.

        (since Linux 3.8)

      • MAP_HUGE_1GB - See MAP_HUGE_2MB.
      • MAP_LOCKED -
      • MAP_NONBLOCK -
      • MAP_NORESERVE -
      • MAP_POPULATE -
      • MAP_STACK -
      • MAP_SYNC -
      • MAP_UNINITIALIZED -
      See Also:

    • MAP_FIXED

      public static final int MAP_FIXED
      Enum values:
      • MAP_32BIT - Put the mapping into the first 2 Gigabytes of the process address space.

        This flag is supported only on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2 GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance problem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set.

      • MAP_ANONYMOUS - The mapping is not backed by any file; its contents are initialized to zero.

        The fd argument is ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The offset argument should be zero. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is supported on Linux only since kernel 2.4.

      • MAP_ANON - Synonym for MAP_ANONYMOUS; provided for compatibility with other implementations.
      • MAP_DENYWRITE - This flag is ignored.

        (Long ago —Linux 2.0 and earlier— it signaled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial-of-service attacks.)

      • MAP_EXECUTABLE - This flag is ignored.
      • MAP_FILE - Compatibility flag. Ignored.
      • MAP_FIXED - Don't interpret addr as a hint: place the mapping at exactly that address.

        addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions. If the memory region specified by addr and length overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap(java.nio.IntBuffer, long, long, int, int, int, long) will fail.

        Software that aspires to be portable should use the MAP_FIXED flag with care, keeping in mind that the exact layout of a process's memory mappings is allowed to change significantly between kernel versions, C library versions, and operating system releases. Carefully read the discussion of this flag in NOTES!

      • MAP_FIXED_NOREPLACE - This flag provides behavior that is similar to MAP_FIXED with respect to the addr enforcement, but differs in that MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.

        If the requested range would collide with an existing mapping, then this call fails with the error EEXIST. This flag can therefore be used as a way to atomically (with respect to other threads) attempt to map an address range: one thread will succeed; all others will report failure.

        Note that older kernels which do not recognize the MAP_FIXED_NOREPLACE flag will typically (upon detecting a collision with a preexisting mapping) fall back to a "non-MAP_FIXED" type of behavior: they will return an address that is different from the requested address. Therefore, backward-compatible software should check the returned address against the requested address.

        (since Linux 4.17)

      • MAP_GROWSDOWN - This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory.

        The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page. This growth can be repeated until the mapping grows to within a page of the high end of the next lower mapping, at which point touching the "guard" page will result in a SIGSEGV signal.

      • MAP_HUGETLB - Allocate the mapping using "huge" pages.

        See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst for further information, as well as NOTES, below.

        (since Linux 2.6.32)

      • MAP_HUGE_2MB - Used in conjunction with MAP_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

        More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset MAP_HUGE_SHIFT. (A value of zero in this bit field provides the default huge page size; the default huge page size can be discovered via the Hugepagesize field exposed by /proc/meminfo.) Thus, the above two constants are defined as:

        
 #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
 #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)

        The range of huge page sizes that are supported by the system can be discovered by listing the subdirectories in /sys/kernel/mm/hugepages.

        (since Linux 3.8)

      • MAP_HUGE_1GB - See MAP_HUGE_2MB.
      • MAP_LOCKED -
      • MAP_NONBLOCK -
      • MAP_NORESERVE -
      • MAP_POPULATE -
      • MAP_STACK -
      • MAP_SYNC -
      • MAP_UNINITIALIZED -
      See Also:

    • MAP_FIXED_NOREPLACE

      public static final int MAP_FIXED_NOREPLACE
      Enum values:
      • MAP_32BIT - Put the mapping into the first 2 Gigabytes of the process address space.

        This flag is supported only on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2 GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance problem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set.

      • MAP_ANONYMOUS - The mapping is not backed by any file; its contents are initialized to zero.

        The fd argument is ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The offset argument should be zero. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is supported on Linux only since kernel 2.4.

      • MAP_ANON - Synonym for MAP_ANONYMOUS; provided for compatibility with other implementations.
      • MAP_DENYWRITE - This flag is ignored.

        (Long ago —Linux 2.0 and earlier— it signaled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial-of-service attacks.)

      • MAP_EXECUTABLE - This flag is ignored.
      • MAP_FILE - Compatibility flag. Ignored.
      • MAP_FIXED - Don't interpret addr as a hint: place the mapping at exactly that address.

        addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions. If the memory region specified by addr and length overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap(java.nio.IntBuffer, long, long, int, int, int, long) will fail.

        Software that aspires to be portable should use the MAP_FIXED flag with care, keeping in mind that the exact layout of a process's memory mappings is allowed to change significantly between kernel versions, C library versions, and operating system releases. Carefully read the discussion of this flag in NOTES!

      • MAP_FIXED_NOREPLACE - This flag provides behavior that is similar to MAP_FIXED with respect to the addr enforcement, but differs in that MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.

        If the requested range would collide with an existing mapping, then this call fails with the error EEXIST. This flag can therefore be used as a way to atomically (with respect to other threads) attempt to map an address range: one thread will succeed; all others will report failure.

        Note that older kernels which do not recognize the MAP_FIXED_NOREPLACE flag will typically (upon detecting a collision with a preexisting mapping) fall back to a "non-MAP_FIXED" type of behavior: they will return an address that is different from the requested address. Therefore, backward-compatible software should check the returned address against the requested address.

        (since Linux 4.17)

      • MAP_GROWSDOWN - This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory.

        The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page. This growth can be repeated until the mapping grows to within a page of the high end of the next lower mapping, at which point touching the "guard" page will result in a SIGSEGV signal.

      • MAP_HUGETLB - Allocate the mapping using "huge" pages.

        See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst for further information, as well as NOTES, below.

        (since Linux 2.6.32)

      • MAP_HUGE_2MB - Used in conjunction with MAP_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

        More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset MAP_HUGE_SHIFT. (A value of zero in this bit field provides the default huge page size; the default huge page size can be discovered via the Hugepagesize field exposed by /proc/meminfo.) Thus, the above two constants are defined as:

        
 #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
 #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)

        The range of huge page sizes that are supported by the system can be discovered by listing the subdirectories in /sys/kernel/mm/hugepages.

        (since Linux 3.8)

      • MAP_HUGE_1GB - See MAP_HUGE_2MB.
      • MAP_LOCKED -
      • MAP_NONBLOCK -
      • MAP_NORESERVE -
      • MAP_POPULATE -
      • MAP_STACK -
      • MAP_SYNC -
      • MAP_UNINITIALIZED -
      See Also:

    • MAP_GROWSDOWN

      public static final int MAP_GROWSDOWN
      Enum values:
      • MAP_32BIT - Put the mapping into the first 2 Gigabytes of the process address space.

        This flag is supported only on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2 GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance problem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set.

      • MAP_ANONYMOUS - The mapping is not backed by any file; its contents are initialized to zero.

        The fd argument is ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The offset argument should be zero. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is supported on Linux only since kernel 2.4.

      • MAP_ANON - Synonym for MAP_ANONYMOUS; provided for compatibility with other implementations.
      • MAP_DENYWRITE - This flag is ignored.

        (Long ago —Linux 2.0 and earlier— it signaled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial-of-service attacks.)

      • MAP_EXECUTABLE - This flag is ignored.
      • MAP_FILE - Compatibility flag. Ignored.
      • MAP_FIXED - Don't interpret addr as a hint: place the mapping at exactly that address.

        addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions. If the memory region specified by addr and length overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap(java.nio.IntBuffer, long, long, int, int, int, long) will fail.

        Software that aspires to be portable should use the MAP_FIXED flag with care, keeping in mind that the exact layout of a process's memory mappings is allowed to change significantly between kernel versions, C library versions, and operating system releases. Carefully read the discussion of this flag in NOTES!

      • MAP_FIXED_NOREPLACE - This flag provides behavior that is similar to MAP_FIXED with respect to the addr enforcement, but differs in that MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.

        If the requested range would collide with an existing mapping, then this call fails with the error EEXIST. This flag can therefore be used as a way to atomically (with respect to other threads) attempt to map an address range: one thread will succeed; all others will report failure.

        Note that older kernels which do not recognize the MAP_FIXED_NOREPLACE flag will typically (upon detecting a collision with a preexisting mapping) fall back to a "non-MAP_FIXED" type of behavior: they will return an address that is different from the requested address. Therefore, backward-compatible software should check the returned address against the requested address.

        (since Linux 4.17)

      • MAP_GROWSDOWN - This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory.

        The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page. This growth can be repeated until the mapping grows to within a page of the high end of the next lower mapping, at which point touching the "guard" page will result in a SIGSEGV signal.

      • MAP_HUGETLB - Allocate the mapping using "huge" pages.

        See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst for further information, as well as NOTES, below.

        (since Linux 2.6.32)

      • MAP_HUGE_2MB - Used in conjunction with MAP_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

        More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset MAP_HUGE_SHIFT. (A value of zero in this bit field provides the default huge page size; the default huge page size can be discovered via the Hugepagesize field exposed by /proc/meminfo.) Thus, the above two constants are defined as:

        
 #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
 #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)

        The range of huge page sizes that are supported by the system can be discovered by listing the subdirectories in /sys/kernel/mm/hugepages.

        (since Linux 3.8)

      • MAP_HUGE_1GB - See MAP_HUGE_2MB.
      • MAP_LOCKED -
      • MAP_NONBLOCK -
      • MAP_NORESERVE -
      • MAP_POPULATE -
      • MAP_STACK -
      • MAP_SYNC -
      • MAP_UNINITIALIZED -
      See Also:

    • MAP_HUGETLB

      public static final int MAP_HUGETLB
      Enum values:
      • MAP_32BIT - Put the mapping into the first 2 Gigabytes of the process address space.

        This flag is supported only on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2 GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance problem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set.

      • MAP_ANONYMOUS - The mapping is not backed by any file; its contents are initialized to zero.

        The fd argument is ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The offset argument should be zero. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is supported on Linux only since kernel 2.4.

      • MAP_ANON - Synonym for MAP_ANONYMOUS; provided for compatibility with other implementations.
      • MAP_DENYWRITE - This flag is ignored.

        (Long ago —Linux 2.0 and earlier— it signaled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial-of-service attacks.)

      • MAP_EXECUTABLE - This flag is ignored.
      • MAP_FILE - Compatibility flag. Ignored.
      • MAP_FIXED - Don't interpret addr as a hint: place the mapping at exactly that address.

        addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions. If the memory region specified by addr and length overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap(java.nio.IntBuffer, long, long, int, int, int, long) will fail.

        Software that aspires to be portable should use the MAP_FIXED flag with care, keeping in mind that the exact layout of a process's memory mappings is allowed to change significantly between kernel versions, C library versions, and operating system releases. Carefully read the discussion of this flag in NOTES!

      • MAP_FIXED_NOREPLACE - This flag provides behavior that is similar to MAP_FIXED with respect to the addr enforcement, but differs in that MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.

        If the requested range would collide with an existing mapping, then this call fails with the error EEXIST. This flag can therefore be used as a way to atomically (with respect to other threads) attempt to map an address range: one thread will succeed; all others will report failure.

        Note that older kernels which do not recognize the MAP_FIXED_NOREPLACE flag will typically (upon detecting a collision with a preexisting mapping) fall back to a "non-MAP_FIXED" type of behavior: they will return an address that is different from the requested address. Therefore, backward-compatible software should check the returned address against the requested address.

        (since Linux 4.17)

      • MAP_GROWSDOWN - This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory.

        The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page. This growth can be repeated until the mapping grows to within a page of the high end of the next lower mapping, at which point touching the "guard" page will result in a SIGSEGV signal.

      • MAP_HUGETLB - Allocate the mapping using "huge" pages.

        See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst for further information, as well as NOTES, below.

        (since Linux 2.6.32)

      • MAP_HUGE_2MB - Used in conjunction with MAP_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

        More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset MAP_HUGE_SHIFT. (A value of zero in this bit field provides the default huge page size; the default huge page size can be discovered via the Hugepagesize field exposed by /proc/meminfo.) Thus, the above two constants are defined as:

        
 #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
 #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)

        The range of huge page sizes that are supported by the system can be discovered by listing the subdirectories in /sys/kernel/mm/hugepages.

        (since Linux 3.8)

      • MAP_HUGE_1GB - See MAP_HUGE_2MB.
      • MAP_LOCKED -
      • MAP_NONBLOCK -
      • MAP_NORESERVE -
      • MAP_POPULATE -
      • MAP_STACK -
      • MAP_SYNC -
      • MAP_UNINITIALIZED -
      See Also:

    • MAP_HUGE_2MB

      public static final int MAP_HUGE_2MB
      Enum values:
      • MAP_32BIT - Put the mapping into the first 2 Gigabytes of the process address space.

        This flag is supported only on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2 GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance problem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set.

      • MAP_ANONYMOUS - The mapping is not backed by any file; its contents are initialized to zero.

        The fd argument is ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The offset argument should be zero. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is supported on Linux only since kernel 2.4.

      • MAP_ANON - Synonym for MAP_ANONYMOUS; provided for compatibility with other implementations.
      • MAP_DENYWRITE - This flag is ignored.

        (Long ago —Linux 2.0 and earlier— it signaled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial-of-service attacks.)

      • MAP_EXECUTABLE - This flag is ignored.
      • MAP_FILE - Compatibility flag. Ignored.
      • MAP_FIXED - Don't interpret addr as a hint: place the mapping at exactly that address.

        addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions. If the memory region specified by addr and length overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap(java.nio.IntBuffer, long, long, int, int, int, long) will fail.

        Software that aspires to be portable should use the MAP_FIXED flag with care, keeping in mind that the exact layout of a process's memory mappings is allowed to change significantly between kernel versions, C library versions, and operating system releases. Carefully read the discussion of this flag in NOTES!

      • MAP_FIXED_NOREPLACE - This flag provides behavior that is similar to MAP_FIXED with respect to the addr enforcement, but differs in that MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.

        If the requested range would collide with an existing mapping, then this call fails with the error EEXIST. This flag can therefore be used as a way to atomically (with respect to other threads) attempt to map an address range: one thread will succeed; all others will report failure.

        Note that older kernels which do not recognize the MAP_FIXED_NOREPLACE flag will typically (upon detecting a collision with a preexisting mapping) fall back to a "non-MAP_FIXED" type of behavior: they will return an address that is different from the requested address. Therefore, backward-compatible software should check the returned address against the requested address.

        (since Linux 4.17)

      • MAP_GROWSDOWN - This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory.

        The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page. This growth can be repeated until the mapping grows to within a page of the high end of the next lower mapping, at which point touching the "guard" page will result in a SIGSEGV signal.

      • MAP_HUGETLB - Allocate the mapping using "huge" pages.

        See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst for further information, as well as NOTES, below.

        (since Linux 2.6.32)

      • MAP_HUGE_2MB - Used in conjunction with MAP_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

        More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset MAP_HUGE_SHIFT. (A value of zero in this bit field provides the default huge page size; the default huge page size can be discovered via the Hugepagesize field exposed by /proc/meminfo.) Thus, the above two constants are defined as:

        
 #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
 #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)

        The range of huge page sizes that are supported by the system can be discovered by listing the subdirectories in /sys/kernel/mm/hugepages.

        (since Linux 3.8)

      • MAP_HUGE_1GB - See MAP_HUGE_2MB.
      • MAP_LOCKED -
      • MAP_NONBLOCK -
      • MAP_NORESERVE -
      • MAP_POPULATE -
      • MAP_STACK -
      • MAP_SYNC -
      • MAP_UNINITIALIZED -
      See Also:

    • MAP_HUGE_1GB

      public static final int MAP_HUGE_1GB
      Enum values:
      • MAP_32BIT - Put the mapping into the first 2 Gigabytes of the process address space.

        This flag is supported only on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2 GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance problem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set.

      • MAP_ANONYMOUS - The mapping is not backed by any file; its contents are initialized to zero.

        The fd argument is ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The offset argument should be zero. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is supported on Linux only since kernel 2.4.

      • MAP_ANON - Synonym for MAP_ANONYMOUS; provided for compatibility with other implementations.
      • MAP_DENYWRITE - This flag is ignored.

        (Long ago —Linux 2.0 and earlier— it signaled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial-of-service attacks.)

      • MAP_EXECUTABLE - This flag is ignored.
      • MAP_FILE - Compatibility flag. Ignored.
      • MAP_FIXED - Don't interpret addr as a hint: place the mapping at exactly that address.

        addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions. If the memory region specified by addr and length overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap(java.nio.IntBuffer, long, long, int, int, int, long) will fail.

        Software that aspires to be portable should use the MAP_FIXED flag with care, keeping in mind that the exact layout of a process's memory mappings is allowed to change significantly between kernel versions, C library versions, and operating system releases. Carefully read the discussion of this flag in NOTES!

      • MAP_FIXED_NOREPLACE - This flag provides behavior that is similar to MAP_FIXED with respect to the addr enforcement, but differs in that MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.

        If the requested range would collide with an existing mapping, then this call fails with the error EEXIST. This flag can therefore be used as a way to atomically (with respect to other threads) attempt to map an address range: one thread will succeed; all others will report failure.

        Note that older kernels which do not recognize the MAP_FIXED_NOREPLACE flag will typically (upon detecting a collision with a preexisting mapping) fall back to a "non-MAP_FIXED" type of behavior: they will return an address that is different from the requested address. Therefore, backward-compatible software should check the returned address against the requested address.

        (since Linux 4.17)

      • MAP_GROWSDOWN - This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory.

        The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page. This growth can be repeated until the mapping grows to within a page of the high end of the next lower mapping, at which point touching the "guard" page will result in a SIGSEGV signal.

      • MAP_HUGETLB - Allocate the mapping using "huge" pages.

        See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst for further information, as well as NOTES, below.

        (since Linux 2.6.32)

      • MAP_HUGE_2MB - Used in conjunction with MAP_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

        More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset MAP_HUGE_SHIFT. (A value of zero in this bit field provides the default huge page size; the default huge page size can be discovered via the Hugepagesize field exposed by /proc/meminfo.) Thus, the above two constants are defined as:

        
 #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
 #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)

        The range of huge page sizes that are supported by the system can be discovered by listing the subdirectories in /sys/kernel/mm/hugepages.

        (since Linux 3.8)

      • MAP_HUGE_1GB - See MAP_HUGE_2MB.
      • MAP_LOCKED -
      • MAP_NONBLOCK -
      • MAP_NORESERVE -
      • MAP_POPULATE -
      • MAP_STACK -
      • MAP_SYNC -
      • MAP_UNINITIALIZED -
      See Also:

    • MAP_LOCKED

      public static final int MAP_LOCKED
      Enum values:
      • MAP_32BIT - Put the mapping into the first 2 Gigabytes of the process address space.

        This flag is supported only on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2 GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance problem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set.

      • MAP_ANONYMOUS - The mapping is not backed by any file; its contents are initialized to zero.

        The fd argument is ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The offset argument should be zero. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is supported on Linux only since kernel 2.4.

      • MAP_ANON - Synonym for MAP_ANONYMOUS; provided for compatibility with other implementations.
      • MAP_DENYWRITE - This flag is ignored.

        (Long ago —Linux 2.0 and earlier— it signaled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial-of-service attacks.)

      • MAP_EXECUTABLE - This flag is ignored.
      • MAP_FILE - Compatibility flag. Ignored.
      • MAP_FIXED - Don't interpret addr as a hint: place the mapping at exactly that address.

        addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions. If the memory region specified by addr and length overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap(java.nio.IntBuffer, long, long, int, int, int, long) will fail.

        Software that aspires to be portable should use the MAP_FIXED flag with care, keeping in mind that the exact layout of a process's memory mappings is allowed to change significantly between kernel versions, C library versions, and operating system releases. Carefully read the discussion of this flag in NOTES!

      • MAP_FIXED_NOREPLACE - This flag provides behavior that is similar to MAP_FIXED with respect to the addr enforcement, but differs in that MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.

        If the requested range would collide with an existing mapping, then this call fails with the error EEXIST. This flag can therefore be used as a way to atomically (with respect to other threads) attempt to map an address range: one thread will succeed; all others will report failure.

        Note that older kernels which do not recognize the MAP_FIXED_NOREPLACE flag will typically (upon detecting a collision with a preexisting mapping) fall back to a "non-MAP_FIXED" type of behavior: they will return an address that is different from the requested address. Therefore, backward-compatible software should check the returned address against the requested address.

        (since Linux 4.17)

      • MAP_GROWSDOWN - This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory.

        The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page. This growth can be repeated until the mapping grows to within a page of the high end of the next lower mapping, at which point touching the "guard" page will result in a SIGSEGV signal.

      • MAP_HUGETLB - Allocate the mapping using "huge" pages.

        See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst for further information, as well as NOTES, below.

        (since Linux 2.6.32)

      • MAP_HUGE_2MB - Used in conjunction with MAP_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

        More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset MAP_HUGE_SHIFT. (A value of zero in this bit field provides the default huge page size; the default huge page size can be discovered via the Hugepagesize field exposed by /proc/meminfo.) Thus, the above two constants are defined as:

        
 #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
 #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)

        The range of huge page sizes that are supported by the system can be discovered by listing the subdirectories in /sys/kernel/mm/hugepages.

        (since Linux 3.8)

      • MAP_HUGE_1GB - See MAP_HUGE_2MB.
      • MAP_LOCKED -
      • MAP_NONBLOCK -
      • MAP_NORESERVE -
      • MAP_POPULATE -
      • MAP_STACK -
      • MAP_SYNC -
      • MAP_UNINITIALIZED -
      See Also:

    • MAP_NONBLOCK

      public static final int MAP_NONBLOCK
      Enum values:
      • MAP_32BIT - Put the mapping into the first 2 Gigabytes of the process address space.

        This flag is supported only on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2 GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance problem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set.

      • MAP_ANONYMOUS - The mapping is not backed by any file; its contents are initialized to zero.

        The fd argument is ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The offset argument should be zero. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is supported on Linux only since kernel 2.4.

      • MAP_ANON - Synonym for MAP_ANONYMOUS; provided for compatibility with other implementations.
      • MAP_DENYWRITE - This flag is ignored.

        (Long ago —Linux 2.0 and earlier— it signaled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial-of-service attacks.)

      • MAP_EXECUTABLE - This flag is ignored.
      • MAP_FILE - Compatibility flag. Ignored.
      • MAP_FIXED - Don't interpret addr as a hint: place the mapping at exactly that address.

        addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions. If the memory region specified by addr and length overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap(java.nio.IntBuffer, long, long, int, int, int, long) will fail.

        Software that aspires to be portable should use the MAP_FIXED flag with care, keeping in mind that the exact layout of a process's memory mappings is allowed to change significantly between kernel versions, C library versions, and operating system releases. Carefully read the discussion of this flag in NOTES!

      • MAP_FIXED_NOREPLACE - This flag provides behavior that is similar to MAP_FIXED with respect to the addr enforcement, but differs in that MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.

        If the requested range would collide with an existing mapping, then this call fails with the error EEXIST. This flag can therefore be used as a way to atomically (with respect to other threads) attempt to map an address range: one thread will succeed; all others will report failure.

        Note that older kernels which do not recognize the MAP_FIXED_NOREPLACE flag will typically (upon detecting a collision with a preexisting mapping) fall back to a "non-MAP_FIXED" type of behavior: they will return an address that is different from the requested address. Therefore, backward-compatible software should check the returned address against the requested address.

        (since Linux 4.17)

      • MAP_GROWSDOWN - This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory.

        The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page. This growth can be repeated until the mapping grows to within a page of the high end of the next lower mapping, at which point touching the "guard" page will result in a SIGSEGV signal.

      • MAP_HUGETLB - Allocate the mapping using "huge" pages.

        See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst for further information, as well as NOTES, below.

        (since Linux 2.6.32)

      • MAP_HUGE_2MB - Used in conjunction with MAP_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

        More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset MAP_HUGE_SHIFT. (A value of zero in this bit field provides the default huge page size; the default huge page size can be discovered via the Hugepagesize field exposed by /proc/meminfo.) Thus, the above two constants are defined as:

        
 #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
 #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)

        The range of huge page sizes that are supported by the system can be discovered by listing the subdirectories in /sys/kernel/mm/hugepages.

        (since Linux 3.8)

      • MAP_HUGE_1GB - See MAP_HUGE_2MB.
      • MAP_LOCKED -
      • MAP_NONBLOCK -
      • MAP_NORESERVE -
      • MAP_POPULATE -
      • MAP_STACK -
      • MAP_SYNC -
      • MAP_UNINITIALIZED -
      See Also:

    • MAP_NORESERVE

      public static final int MAP_NORESERVE
      Enum values:
      • MAP_32BIT - Put the mapping into the first 2 Gigabytes of the process address space.

        This flag is supported only on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2 GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance problem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set.

      • MAP_ANONYMOUS - The mapping is not backed by any file; its contents are initialized to zero.

        The fd argument is ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The offset argument should be zero. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is supported on Linux only since kernel 2.4.

      • MAP_ANON - Synonym for MAP_ANONYMOUS; provided for compatibility with other implementations.
      • MAP_DENYWRITE - This flag is ignored.

        (Long ago —Linux 2.0 and earlier— it signaled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial-of-service attacks.)

      • MAP_EXECUTABLE - This flag is ignored.
      • MAP_FILE - Compatibility flag. Ignored.
      • MAP_FIXED - Don't interpret addr as a hint: place the mapping at exactly that address.

        addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions. If the memory region specified by addr and length overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap(java.nio.IntBuffer, long, long, int, int, int, long) will fail.

        Software that aspires to be portable should use the MAP_FIXED flag with care, keeping in mind that the exact layout of a process's memory mappings is allowed to change significantly between kernel versions, C library versions, and operating system releases. Carefully read the discussion of this flag in NOTES!

      • MAP_FIXED_NOREPLACE - This flag provides behavior that is similar to MAP_FIXED with respect to the addr enforcement, but differs in that MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.

        If the requested range would collide with an existing mapping, then this call fails with the error EEXIST. This flag can therefore be used as a way to atomically (with respect to other threads) attempt to map an address range: one thread will succeed; all others will report failure.

        Note that older kernels which do not recognize the MAP_FIXED_NOREPLACE flag will typically (upon detecting a collision with a preexisting mapping) fall back to a "non-MAP_FIXED" type of behavior: they will return an address that is different from the requested address. Therefore, backward-compatible software should check the returned address against the requested address.

        (since Linux 4.17)

      • MAP_GROWSDOWN - This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory.

        The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page. This growth can be repeated until the mapping grows to within a page of the high end of the next lower mapping, at which point touching the "guard" page will result in a SIGSEGV signal.

      • MAP_HUGETLB - Allocate the mapping using "huge" pages.

        See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst for further information, as well as NOTES, below.

        (since Linux 2.6.32)

      • MAP_HUGE_2MB - Used in conjunction with MAP_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

        More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset MAP_HUGE_SHIFT. (A value of zero in this bit field provides the default huge page size; the default huge page size can be discovered via the Hugepagesize field exposed by /proc/meminfo.) Thus, the above two constants are defined as:

        
 #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
 #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)

        The range of huge page sizes that are supported by the system can be discovered by listing the subdirectories in /sys/kernel/mm/hugepages.

        (since Linux 3.8)

      • MAP_HUGE_1GB - See MAP_HUGE_2MB.
      • MAP_LOCKED -
      • MAP_NONBLOCK -
      • MAP_NORESERVE -
      • MAP_POPULATE -
      • MAP_STACK -
      • MAP_SYNC -
      • MAP_UNINITIALIZED -
      See Also:

    • MAP_POPULATE

      public static final int MAP_POPULATE
      Enum values:
      • MAP_32BIT - Put the mapping into the first 2 Gigabytes of the process address space.

        This flag is supported only on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2 GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance problem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set.

      • MAP_ANONYMOUS - The mapping is not backed by any file; its contents are initialized to zero.

        The fd argument is ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The offset argument should be zero. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is supported on Linux only since kernel 2.4.

      • MAP_ANON - Synonym for MAP_ANONYMOUS; provided for compatibility with other implementations.
      • MAP_DENYWRITE - This flag is ignored.

        (Long ago —Linux 2.0 and earlier— it signaled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial-of-service attacks.)

      • MAP_EXECUTABLE - This flag is ignored.
      • MAP_FILE - Compatibility flag. Ignored.
      • MAP_FIXED - Don't interpret addr as a hint: place the mapping at exactly that address.

        addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions. If the memory region specified by addr and length overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap(java.nio.IntBuffer, long, long, int, int, int, long) will fail.

        Software that aspires to be portable should use the MAP_FIXED flag with care, keeping in mind that the exact layout of a process's memory mappings is allowed to change significantly between kernel versions, C library versions, and operating system releases. Carefully read the discussion of this flag in NOTES!

      • MAP_FIXED_NOREPLACE - This flag provides behavior that is similar to MAP_FIXED with respect to the addr enforcement, but differs in that MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.

        If the requested range would collide with an existing mapping, then this call fails with the error EEXIST. This flag can therefore be used as a way to atomically (with respect to other threads) attempt to map an address range: one thread will succeed; all others will report failure.

        Note that older kernels which do not recognize the MAP_FIXED_NOREPLACE flag will typically (upon detecting a collision with a preexisting mapping) fall back to a "non-MAP_FIXED" type of behavior: they will return an address that is different from the requested address. Therefore, backward-compatible software should check the returned address against the requested address.

        (since Linux 4.17)

      • MAP_GROWSDOWN - This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory.

        The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page. This growth can be repeated until the mapping grows to within a page of the high end of the next lower mapping, at which point touching the "guard" page will result in a SIGSEGV signal.

      • MAP_HUGETLB - Allocate the mapping using "huge" pages.

        See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst for further information, as well as NOTES, below.

        (since Linux 2.6.32)

      • MAP_HUGE_2MB - Used in conjunction with MAP_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

        More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset MAP_HUGE_SHIFT. (A value of zero in this bit field provides the default huge page size; the default huge page size can be discovered via the Hugepagesize field exposed by /proc/meminfo.) Thus, the above two constants are defined as:

        
 #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
 #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)

        The range of huge page sizes that are supported by the system can be discovered by listing the subdirectories in /sys/kernel/mm/hugepages.

        (since Linux 3.8)

      • MAP_HUGE_1GB - See MAP_HUGE_2MB.
      • MAP_LOCKED -
      • MAP_NONBLOCK -
      • MAP_NORESERVE -
      • MAP_POPULATE -
      • MAP_STACK -
      • MAP_SYNC -
      • MAP_UNINITIALIZED -
      See Also:

    • MAP_STACK

      public static final int MAP_STACK
      Enum values:
      • MAP_32BIT - Put the mapping into the first 2 Gigabytes of the process address space.

        This flag is supported only on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2 GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance problem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set.

      • MAP_ANONYMOUS - The mapping is not backed by any file; its contents are initialized to zero.

        The fd argument is ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The offset argument should be zero. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is supported on Linux only since kernel 2.4.

      • MAP_ANON - Synonym for MAP_ANONYMOUS; provided for compatibility with other implementations.
      • MAP_DENYWRITE - This flag is ignored.

        (Long ago —Linux 2.0 and earlier— it signaled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial-of-service attacks.)

      • MAP_EXECUTABLE - This flag is ignored.
      • MAP_FILE - Compatibility flag. Ignored.
      • MAP_FIXED - Don't interpret addr as a hint: place the mapping at exactly that address.

        addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions. If the memory region specified by addr and length overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap(java.nio.IntBuffer, long, long, int, int, int, long) will fail.

        Software that aspires to be portable should use the MAP_FIXED flag with care, keeping in mind that the exact layout of a process's memory mappings is allowed to change significantly between kernel versions, C library versions, and operating system releases. Carefully read the discussion of this flag in NOTES!

      • MAP_FIXED_NOREPLACE - This flag provides behavior that is similar to MAP_FIXED with respect to the addr enforcement, but differs in that MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.

        If the requested range would collide with an existing mapping, then this call fails with the error EEXIST. This flag can therefore be used as a way to atomically (with respect to other threads) attempt to map an address range: one thread will succeed; all others will report failure.

        Note that older kernels which do not recognize the MAP_FIXED_NOREPLACE flag will typically (upon detecting a collision with a preexisting mapping) fall back to a "non-MAP_FIXED" type of behavior: they will return an address that is different from the requested address. Therefore, backward-compatible software should check the returned address against the requested address.

        (since Linux 4.17)

      • MAP_GROWSDOWN - This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory.

        The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page. This growth can be repeated until the mapping grows to within a page of the high end of the next lower mapping, at which point touching the "guard" page will result in a SIGSEGV signal.

      • MAP_HUGETLB - Allocate the mapping using "huge" pages.

        See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst for further information, as well as NOTES, below.

        (since Linux 2.6.32)

      • MAP_HUGE_2MB - Used in conjunction with MAP_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

        More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset MAP_HUGE_SHIFT. (A value of zero in this bit field provides the default huge page size; the default huge page size can be discovered via the Hugepagesize field exposed by /proc/meminfo.) Thus, the above two constants are defined as:

        
 #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
 #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)

        The range of huge page sizes that are supported by the system can be discovered by listing the subdirectories in /sys/kernel/mm/hugepages.

        (since Linux 3.8)

      • MAP_HUGE_1GB - See MAP_HUGE_2MB.
      • MAP_LOCKED -
      • MAP_NONBLOCK -
      • MAP_NORESERVE -
      • MAP_POPULATE -
      • MAP_STACK -
      • MAP_SYNC -
      • MAP_UNINITIALIZED -
      See Also:

    • MAP_SYNC

      public static final int MAP_SYNC
      Enum values:
      • MAP_32BIT - Put the mapping into the first 2 Gigabytes of the process address space.

        This flag is supported only on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2 GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance problem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set.

      • MAP_ANONYMOUS - The mapping is not backed by any file; its contents are initialized to zero.

        The fd argument is ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The offset argument should be zero. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is supported on Linux only since kernel 2.4.

      • MAP_ANON - Synonym for MAP_ANONYMOUS; provided for compatibility with other implementations.
      • MAP_DENYWRITE - This flag is ignored.

        (Long ago —Linux 2.0 and earlier— it signaled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial-of-service attacks.)

      • MAP_EXECUTABLE - This flag is ignored.
      • MAP_FILE - Compatibility flag. Ignored.
      • MAP_FIXED - Don't interpret addr as a hint: place the mapping at exactly that address.

        addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions. If the memory region specified by addr and length overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap(java.nio.IntBuffer, long, long, int, int, int, long) will fail.

        Software that aspires to be portable should use the MAP_FIXED flag with care, keeping in mind that the exact layout of a process's memory mappings is allowed to change significantly between kernel versions, C library versions, and operating system releases. Carefully read the discussion of this flag in NOTES!

      • MAP_FIXED_NOREPLACE - This flag provides behavior that is similar to MAP_FIXED with respect to the addr enforcement, but differs in that MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.

        If the requested range would collide with an existing mapping, then this call fails with the error EEXIST. This flag can therefore be used as a way to atomically (with respect to other threads) attempt to map an address range: one thread will succeed; all others will report failure.

        Note that older kernels which do not recognize the MAP_FIXED_NOREPLACE flag will typically (upon detecting a collision with a preexisting mapping) fall back to a "non-MAP_FIXED" type of behavior: they will return an address that is different from the requested address. Therefore, backward-compatible software should check the returned address against the requested address.

        (since Linux 4.17)

      • MAP_GROWSDOWN - This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory.

        The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page. This growth can be repeated until the mapping grows to within a page of the high end of the next lower mapping, at which point touching the "guard" page will result in a SIGSEGV signal.

      • MAP_HUGETLB - Allocate the mapping using "huge" pages.

        See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst for further information, as well as NOTES, below.

        (since Linux 2.6.32)

      • MAP_HUGE_2MB - Used in conjunction with MAP_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

        More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset MAP_HUGE_SHIFT. (A value of zero in this bit field provides the default huge page size; the default huge page size can be discovered via the Hugepagesize field exposed by /proc/meminfo.) Thus, the above two constants are defined as:

        
 #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
 #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)

        The range of huge page sizes that are supported by the system can be discovered by listing the subdirectories in /sys/kernel/mm/hugepages.

        (since Linux 3.8)

      • MAP_HUGE_1GB - See MAP_HUGE_2MB.
      • MAP_LOCKED -
      • MAP_NONBLOCK -
      • MAP_NORESERVE -
      • MAP_POPULATE -
      • MAP_STACK -
      • MAP_SYNC -
      • MAP_UNINITIALIZED -
      See Also:

    • MAP_UNINITIALIZED

      public static final int MAP_UNINITIALIZED
      Enum values:
      • MAP_32BIT - Put the mapping into the first 2 Gigabytes of the process address space.

        This flag is supported only on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2 GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance problem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set.

      • MAP_ANONYMOUS - The mapping is not backed by any file; its contents are initialized to zero.

        The fd argument is ignored; however, some implementations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The offset argument should be zero. The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is supported on Linux only since kernel 2.4.

      • MAP_ANON - Synonym for MAP_ANONYMOUS; provided for compatibility with other implementations.
      • MAP_DENYWRITE - This flag is ignored.

        (Long ago —Linux 2.0 and earlier— it signaled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial-of-service attacks.)

      • MAP_EXECUTABLE - This flag is ignored.
      • MAP_FILE - Compatibility flag. Ignored.
      • MAP_FIXED - Don't interpret addr as a hint: place the mapping at exactly that address.

        addr must be suitably aligned: for most architectures a multiple of the page size is sufficient; however, some architectures may impose additional restrictions. If the memory region specified by addr and length overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap(java.nio.IntBuffer, long, long, int, int, int, long) will fail.

        Software that aspires to be portable should use the MAP_FIXED flag with care, keeping in mind that the exact layout of a process's memory mappings is allowed to change significantly between kernel versions, C library versions, and operating system releases. Carefully read the discussion of this flag in NOTES!

      • MAP_FIXED_NOREPLACE - This flag provides behavior that is similar to MAP_FIXED with respect to the addr enforcement, but differs in that MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.

        If the requested range would collide with an existing mapping, then this call fails with the error EEXIST. This flag can therefore be used as a way to atomically (with respect to other threads) attempt to map an address range: one thread will succeed; all others will report failure.

        Note that older kernels which do not recognize the MAP_FIXED_NOREPLACE flag will typically (upon detecting a collision with a preexisting mapping) fall back to a "non-MAP_FIXED" type of behavior: they will return an address that is different from the requested address. Therefore, backward-compatible software should check the returned address against the requested address.

        (since Linux 4.17)

      • MAP_GROWSDOWN - This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory.

        The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page. This growth can be repeated until the mapping grows to within a page of the high end of the next lower mapping, at which point touching the "guard" page will result in a SIGSEGV signal.

      • MAP_HUGETLB - Allocate the mapping using "huge" pages.

        See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst for further information, as well as NOTES, below.

        (since Linux 2.6.32)

      • MAP_HUGE_2MB - Used in conjunction with MAP_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that support multiple hugetlb page sizes.

        More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the six bits at the offset MAP_HUGE_SHIFT. (A value of zero in this bit field provides the default huge page size; the default huge page size can be discovered via the Hugepagesize field exposed by /proc/meminfo.) Thus, the above two constants are defined as:

        
 #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
 #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)

        The range of huge page sizes that are supported by the system can be discovered by listing the subdirectories in /sys/kernel/mm/hugepages.

        (since Linux 3.8)

      • MAP_HUGE_1GB - See MAP_HUGE_2MB.
      • MAP_LOCKED -
      • MAP_NONBLOCK -
      • MAP_NORESERVE -
      • MAP_POPULATE -
      • MAP_STACK -
      • MAP_SYNC -
      • MAP_UNINITIALIZED -
      See Also:

  • Method Details

    • nmmap

      public static long nmmap(long _errno, long addr, long length, int prot, int flags, int fd, long offset)
      Unsafe version of: mmap(java.nio.IntBuffer, long, long, int, int, int, long)

    • mmap

      public static long mmap(@Nullable IntBuffer _errno, long addr, long length, int prot, int flags, int fd, long offset)
      Creates a new mapping in the virtual address space of the calling process.

      The starting address for the new mapping is specified in addr. The length argument specifies the length of the mapping (which must be greater than 0).

      If addr is NULL, then the kernel chooses the (page-aligned) address at which to create the mapping; this is the most portable method of creating a new mapping. If addr is not NULL, then the kernel takes it as a hint about where to place the mapping; on Linux, the kernel will pick a nearby page boundary (but always above or equal to the value specified by /proc/sys/vm/mmap_min_addr) and attempt to create the mapping there. If another mapping already exists there, the kernel picks a new address that may or may not depend on the hint. The address of the new mapping is returned as the result of the call.

      The contents of a file mapping (as opposed to an anonymous mapping; see MAP_ANONYMOUS below), are initialized using length bytes starting at offset offset in the file (or other object) referred to by the file descriptor fd. offset must be a multiple of the page size as returned by sysconf(_SC_PAGE_SIZE).

      After the mmap() call has returned, the file descriptor, fd, can be closed immediately without invalidating the mapping.

      Parameters:
      _errno - optionally returns the errno value after this function is called
      prot - describes the desired memory protection of the mapping (and must not conflict with the open mode of the file). One or more of:
      PROT_EXECPROT_READPROT_WRITEPROT_NONEPROT_GROWSDOWNPROT_GROWSUP
      flags - one or more of:
      MAP_FAILEDMAP_SHAREDMAP_SHARED_VALIDATEMAP_PRIVATEMAP_HUGE_SHIFTMAP_HUGE_MASK
      MAP_32BITMAP_ANONYMOUSMAP_ANONMAP_DENYWRITEMAP_EXECUTABLEMAP_FILE
      MAP_FIXEDMAP_FIXED_NOREPLACEMAP_GROWSDOWNMAP_HUGETLBMAP_HUGE_2MBMAP_HUGE_1GB
      MAP_LOCKEDMAP_NONBLOCKMAP_NORESERVEMAP_POPULATEMAP_STACKMAP_SYNC
      MAP_UNINITIALIZED
      Returns:
      on success, returns a pointer to the mapped area. On error, the value MAP_FAILED is returned, and errno is set to indicate the error.

    • nmunmap

      public static int nmunmap(long _errno, long addr, long length)
      Unsafe version of: munmap(java.nio.IntBuffer, java.nio.ByteBuffer)

    • munmap

      public static int munmap(@Nullable IntBuffer _errno, ByteBuffer addr)
      Deletes the mappings for the specified address range, and causes further references to addresses within the range to generate invalid memory references.

      The region is also automatically unmapped when the process is terminated. On the other hand, closing the file descriptor does not unmap the region.

      The address addr must be a multiple of the page size (but length need not be). All pages containing a part of the indicated range are unmapped, and subsequent references to these pages will generate SIGSEGV. It is not an error if the indicated range does not contain any mapped pages.

      Parameters:
      _errno - optionally returns the errno value after this function is called
      Returns:
      on success, returns 0. On failure, it returns -1, and errno is set to indicate the error (probably to EINVAL).