RFR: 8272807: Permit use of memory concurrent with pretouch

[David Holmes]

On Wed, 25 Aug 2021 12:49:11 GMT, Aleksey Shipilev <shade 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.
>
> Thinking some more about this. The conflict I described must be fine, as strong CAS implementations are supposed to guard from the spurious violations like these. Stray ADD(0) (true sharing) is not very different from the stray update to the same cache line (false sharing) in this scenario. (I did check this empirically with JCStress on x86_64 and AArch64, and seem to perform as expected).

@shipilev -right a "strong CAS" has to filter out spurious interference on ll/sc based implementations. That said, how can we be actively using an oop located in a page that we are also in the process of pre-touching?

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

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