RFR: 8272807: Permit use of memory concurrent with pretouch

David Holmes dholmes at openjdk.java.net
Tue Aug 24 00:10:33 UTC 2021


On Mon, 23 Aug 2021 11:35:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to os::pretouch_memory to permit use of the memory
> concurrently with the pretouch operation.  This is accomplished by using an
> atomic add of zero as the operation for touching the memory, ensuring the
> virtual location is backed by physical memory while not changing any values
> being read or written by the application.
> 
> While I was there, fixed some other lurking issues in os::pretouch_memory.
> There was a potential overflow in the iteration that has been fixed.  And if
> the range arguments weren't page aligned then the last page might not get
> touched.  The latter was even mentioned in the function's description.  Both
> of those have been fixed by careful alignment and some extra checks.  The
> resulting code is a little more complicated, but more robust and complete.
> 
> This change doesn't make use of the new capability; I have some other
> changes in development to do that.
> 
> Testing:
> mach5 tier1-3.
> 
> I've been using this change while developing uses of the new capability.
> Performance testing hasn't found any regressions related to this change.

src/hotspot/share/runtime/os.cpp line 1834:

> 1832:   assert(page_size >= sizeof(int), "page size too small: %zu", page_size);
> 1833:   end = align_down(end, sizeof(int));
> 1834:   if (start < end) {

So ... if this were called as follows:
`os::pretouch_memory(page_start, page_start+3, vm_page_size())`
we would not pretouch any pages. That seems wrong - either we should touch one page, or this is an illegal condition and we should preclude it. It seems to me this logic would be much simpler if `start` and `end` were more constrained than they appear to be right now. E.g `start` should be `int`-aligned; `end-start` should be > `sizeof(int)`.

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

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


More information about the hotspot-runtime-dev mailing list