RFR: 8261023: Add comment why memory pretouch must be a store

Thomas Schatzl tschatzl at openjdk.java.net
Wed Feb 3 09:51:52 UTC 2021


Hi all,

  may I have reviews for this additional comment that explains why `os::pretouch_memory` needs to use a store and must not use a read which would be more convenient?

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:

-      // Note the use of a write here; originally we tried just a read, but
-      // 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.

Testing: local compilation - it's adding a comment only, really.

Thanks,
  Thomas

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/2373/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2373&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261023
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2373.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2373/head:pull/2373

PR: https://git.openjdk.java.net/jdk/pull/2373



More information about the hotspot-gc-dev mailing list