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

Document why memory pretouch must be a store

    XMLWordPrintable

Details

    • Enhancement
    • Resolution: Fixed
    • P4
    • 17
    • 17
    • hotspot
    • b09

    Description

      During discussions the question came up why memory pretouch must be a store which would be more convenient in some cases.

      Basically on some (all?) OSes memory pages are only actually backed with physical memory on a store to that page. Before that a common "zero page" may be used to satisfy reads. This is not what is intended here.

      A previous comment (that has been removed long ago) seems to have been a bit confused about the actual issue:

      - // since the value read was unused, the optimizer removed the read.
      - // If we ever have a concurrent touchahead thread, we'll want to use
      - // a read, to avoid the potential of overwriting data (if a mutator
      - // thread beats the touchahead thread to a page). There are various
      - // ways of making sure this read is not optimized away: for example,
      - // generating the code for a read procedure at runtime.

      It indicates that the reason for using a store has been that the compiler would optimize away the reads (which begs the question why a volatile read has not been used).

      Maybe these zero page optimizations came later than that original implementation though.

      Add a comment to os::pretouch_memory so that this will not be forgotten.

      Attachments

        Issue Links

          Activity

            People

              tschatzl Thomas Schatzl
              tschatzl Thomas Schatzl
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: