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

Cleanup: remove alignment_hint parameter from os::reserve_memory

    XMLWordPrintable

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 16
    • Fix Version/s: 16
    • Component/s: hotspot
    • Subcomponent:
    • Resolved In Build:
      b19

      Description

      It's only AIX that honors that hint, and it might not be needed. Maybe some rewrites are necessary, though.

      From [~stuefe]:
      ---

      I believe we can actually do away with the alignment hint for os::reserve_memory altogether. Which would be good because it is strange and not well documented.

      I believe the original intent was to let the OS "do its best" but no OS does; all AIX does (and only in mmap mode) is the same as upper layers do, chopping excess memory at front and back away manually.

      Moreover, that chopping does only work well when using mmap. When using win32 VirtualAlloc or sysv shmat, we cannot unmap part of a mapping.

      On AIX, I basically just implemented it to "do my best", because I wanted to fill in the os::xx API as best as possible; but it is actually not needed, we don't care (there is some alignment magic going on in 64k paged mode with mmap, but that is a different issue).

      If I see it right, there are only two cases where caller request alignment from os::reserve_memory:

          at several places (eg ZMarkStackSpace) I see an alignment used of os::vm_allocation_granularity, which is unnecessary since that is the granularity the OS will reserve at anyway. Also, it only has any meaning on windows.
          I see os::reserve_memory_aligned(), used when creating a ReservedSpace with an alignment wish - which is a real thing, e.g. in metaspace - using the alignment parameter as a wish to os::reserve_memory, but then proceeds to do the alignment-chopping-dance anyway so I guess it is not needed and was just a hopeful optimization.

      ---

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              stuefe Thomas Stuefe
              Reporter:
              stefank Stefan Karlsson
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: