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

Document why memory pretouch must be a store



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


      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.


        Issue Links



              tschatzl Thomas Schatzl
              tschatzl Thomas Schatzl
              0 Vote for this issue
              3 Start watching this issue