RFR: 8317432: Async UL: Do not recompute strlen()

[Xin Liu]

On Wed, 4 Oct 2023 11:27:25 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This change does three things:
>> 
>> 1. At construction of message we used to compute `strlen` and then `strcpy`, we change this to do only one `strlen` and then a `memcpy` instead.
>> 2. A `strlen` used to be required to calculate the size when finding the next message in the iterator. We instead store the previously computed message length and so the `strlen` is no longer necessary. The cost of this is 8 bytes extra per message (64 -> 72 bytes).
>> 3. There's also some code which alters the alignment to explicitly handle the alignment of `Message` and ensure that `_pos` starts at a `Message`-aligned pointer.
>
> Saving the length can be done even earlier in the UL process, both for sync and async UL. This, in turn, allows us to use `fwrite` instead of `jio_fprintf` in `logFileStreamOutput.cpp:128`. Just some small ways of making UL a bit quicker.

hi, @jdksjolen 

I am aware of that we need to calculate strlen in the iterator. I thought that's it's one off thing so I try to leave more room for c-str. My concern is that we have a lot of one liners, so 8 bytes isn't that cheap for them. The second strlen is called in flusher thread anymore. 

I don't oppose the way your implement it. With strlen encoded, we actually can save the zero-terminator '\0' as well. we have to append it when we output c-str. it probably not worthy it. 

I like your other changes. 'alignof' resolves the undefined behavior indeed. Is that the original reason you made this change?

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

PR Comment: https://git.openjdk.org/jdk/pull/16029#issuecomment-1747784568