RFR: 8261023: Add comment why memory pretouch must be a store
Aleksey Shipilev
shade at openjdk.java.net
Wed Feb 3 10:06:45 UTC 2021
On Wed, 3 Feb 2021 09:47:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> 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
Looks fine. Bikeshedding suggestions below.
src/hotspot/share/runtime/os.cpp line 1819:
> 1817: // optimization where only writes trigger actual backing of memory. Reads
> 1818: // access a single shared zero page at first and so will not achieve the
> 1819: // desired effect.
Consider:
Note: this must be a store, not a load. On many OSes loads from the fresh memory would be
satisfied from a single mapped zero page. We need to store something to each page to get
them backed by their own memory, which is what we want as the effect here.
-------------
Marked as reviewed by shade (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/2373
More information about the hotspot-gc-dev
mailing list