RFR: 8272807: Permit use of memory concurrent with pretouch

[Aleksey Shipilev]

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.

Um, a disturbing thought came to me about this. 

Is this intended to allow concurrent heap access by the Java application? Because I think it runs afoul of the guarantees for the strong CAS. Consider two Java threads that perform strong CAS(0 -> 1) on a field, and that field is by luck is on the same offset at which this pre-touching code does ADD(0). From the Java perspective, exactly one of Java CASes should succeed, as long as nothing else writes there from Java. But since VM does another atomic store to the same location, both Java CASes could fail? (I haven't checked this empirically, but it looks plausible.)

This problem looks similar to concurrent heap updates by concurrent GCs, but at least there we have special CAS barriers to handle false negatives. In case of STW GCs, we would have no such luck.

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

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