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.