RFR: 8272807: Permit use of memory concurrent with pretouch

Kim Barrett kbarrett at openjdk.java.net
Sun Aug 29 11:57: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.

[Originally replied on the mailing list, but the mailing list to PR reflector has been unreliable, and didn't pick this up.]

> > That said, how can we be actively using an oop located in a page that we are also in the process of pre-touching?
> I think that is what this patch is supposed to enable: concurrent pretouch. Where "concurrent" might mean "concurrent with application code". For example, init the heap, let the Java code run, and then use a background GC worker to concurrently pre-touch the heap. ("Pre-" becomes a little fuzzy here...).

Among other uses, exactly.

And yes, “Pre-“ is a little fuzzy.  I was originally intending to add a new “concurrent_touch_memory”
or something like that, but I’ve not been able to detect any performance difference between the old
and the new.  I’ll be getting back to Aleksey on that later; I have more measurements I want to run.


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

More information about the hotspot-runtime-dev mailing list