RFR: 8314294: Unsafe::allocateMemory and Unsafe::freeMemory are slower than malloc/free

[David Holmes]

On Fri, 29 Sep 2023 08:17:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> To increase performance by avoiding a thread-state transition (native -> in_vm) we change the three "raw" allocation functions in Unsafe to be UNSAFE_LEAF rather than UNSAFE_ENTRY.
>> 
>> It is hard to track through all the related code to prove this is a safe change, but I could not spot anything obvious and testing indicated no issues (my main concern was potential missing WXWrite on macOS Aarch64).
>> 
>> Testing:
>>   - tiers 1-7 on linux and macos x64 and Aarch64, plus Windows x64
>> 
>> Thanks
>
> Thanks for taking care of this @dholmes-ora. Do you know if Unsafe::copyMemory, or Unsafe::setMemory can also receive same treatment? These are bulk operations, so they are less sensitive to the transition cost - but for small copies it can still be a factor.

@mcimadamore setMemory and copyMemory are targeting Java arrays not native memory so they have to be safepoint-aware and so cannot be leaf operations.

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

PR Comment: https://git.openjdk.org/jdk/pull/15977#issuecomment-1744178613