RFR: 8334599: Improve code from JDK-8302671 [v2]

[Alexey Ivanov]

On Wed, 3 Jul 2024 13:25:27 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp line 3368:
>> 
>>> 3366:     BYTE tmpState[256];
>>> 3367:     WCHAR wc[2];
>>> 3368:     memmove(tmpState, kstate, sizeof(kstate));
>> 
>> Using `memcpy` could be more performant, we know for sure that `tmpState` and `kstate` do not overlap.
>
> I can't quite comment on that since I don't really know what the purpose of the memmove is. What does @prrace think?

Both `memcpy` and `memmove` do the same thing, namely each function copies bytes from one location into another location. The difference between these two functions is in whether buffers are allowed to overlap or not:

* [`memcpy`](https://en.cppreference.com/w/c/string/byte/memcpy): <q cite="https://en.cppreference.com/w/c/string/byte/memcpy">If the objects overlap […], the behavior is undefined.</q><br><q cite="https://en.cppreference.com/w/c/string/byte/memcpy#Notes"><em>`memcpy` is the fastest library routine for memory-to-memory copy.</em> It is usually more efficient than `strcpy`, which must scan the data it copies or `memmove`, which must take precautions to handle overlapping inputs.</q>
* [`memmove`](https://en.cppreference.com/w/c/string/byte/memmove): <q cite="https://en.cppreference.com/w/c/string/byte/memmove">The objects may overlap: copying takes place as if the characters were copied to a temporary character array and then the characters were copied from the array to `dest`.</q>

> we know for sure that `tmpState` and `kstate` do not overlap.

For this reason, `memcpy` is safe to use, and it is more efficient than `memmove`.

To be clear, I'm not proposing to incorporate this change under this bug. I just pointed out a possible optimisation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19798#discussion_r1665654705