RFR: 8351140: RISC-V: Intrinsify Unsafe::setMemory [v14]
Hamlin Li
mli at openjdk.org
Thu May 22 12:41:55 UTC 2025
On Wed, 21 May 2025 12:43:46 GMT, Hamlin Li <mli at openjdk.org> wrote:
>>> > Thanks for your review! I think the above test results may not fully reflect the difference in the impact of aligned and unaligned on the tail? I understand that if the dest address is aligned, the above aligned section has 0 to 4 less store instructions than the following section. I can remove it and test jmh to see how it performs
>>>
>>> Based on your last jmh data (check `MemorySegmentFillUnsafe.unsafe true 7` and `MemorySegmentFillUnsafe.unsafe false 7`, and others <= 7, they're the same. I guess the pipeline and store buffer deal with this continuous stores well enough.
>>
>> The last change on the code after L_fill_elements make the byte store 1 by 1, it seems that 'true' or 'false' may not affect it when the count is less or equal 7?
>> I think the above align section is like a fast path which can reduce instruction for the count is large than 7, so we may should check the result when count > 7 ? besides, I'm testing on that right now(delete the align tail part), we can find it out later
>
>> The last change on the code after L_fill_elements make the byte store 1 by 1, it seems that 'true' or 'false' may not affect it when the count is less or equal 7?
>
> Ah, I see.
>
>> I think the above align section is like a fast path which can reduce instruction for the count is large than 7, so we may should check the result when count > 7 ? besides, I'm testing on that right now(delete the align tail part), we can find it out later
>
> Thanks, let's see the test result.
> @Hamlin-Li The original branch rarely walks, which is almost never tested, and the performance impact of the ‘fast’ path is relatively small. I think you are right, it is suitable to be deleted
Thanks for testing! As there is some regression, maybe it's better to keep it.
Looks good to me.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23890#issuecomment-2901081836
More information about the hotspot-compiler-dev
mailing list