RFR: 8353500: [s390x] Intrinsify Unsafe::setMemory [v4]

Ulrich Weigand duke at openjdk.org
Fri May 9 13:40:54 UTC 2025


On Fri, 9 May 2025 10:43:40 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>>> Hi Martin, So what will be next step here ? Should I put this question in community mailing list ?
>> 
>> You can try. `java.nio` and FFM API may have some requirements and expectations for such `Unsafe` operations.
>
>> > Hi Martin, So what will be next step here ? Should I put this question in community mailing list ?
>> 
>> You can try. `java.nio` and FFM API may have some requirements and expectations for such `Unsafe` operations.
> 
> I couldn't see any failure @TheRealMDoerr

@offamitkumar asked me to comment here w.r.t. s390x architecture questions.  I'm not sure what exactly the requirements are this function needs to guarantee, but the s390x MVC instruction has the following properties:
- It is a single operation as observed by the CPU that executes it, that is it either completes fully or not at all (e.g. in the case of accessing unmapped memory addresses). In that respect it behaves similarly to a single store instruction.
- As observed by *other* CPUs, MVC does not make any guarantee of atomicity (at least not the case where source and destination overlap, which we have in this example).  That is other CPUs may observe in memory either the state before the operation, after the operation, or any intermediate state.  [ In that respect, MVC behaves _differently_ from a store instruction, where e.g. an 8 byte store to a naturally aligned address is guaranteed to be atomic: other CPUs will either see the old value or the new, but not anything in between. ]

So whether or not MVC is the correct choice here depends on the assumptions the callers make on this routine.

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

PR Comment: https://git.openjdk.org/jdk/pull/24480#issuecomment-2866326026


More information about the hotspot-compiler-dev mailing list