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

[Johan Sjölen]

On Wed, 4 Oct 2023 23:27:41 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> 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 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 are not that cheap for them. The second reason is that strlen is called in flusher thread anyway. 
> 
> I don't oppose the way you implement it. Another idea: with strlen encoded, we actually can save the zero-terminator '\0' as well. Of course, 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?

Hi @navyxliu, thank you for taking a look at this.

> I am aware of that we need to calculate strlen in the iterator. I thought that 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 are not that cheap for them. The second reason is that strlen is called in flusher thread anyway.

I understand, I was on the fence about saving or not saving the length. This is a 12.5% increase in the size of the `Message` envelope, so the envelope itself is already quite large compared to the string and I was hoping that we can avoid the `strlen` in the flusher thread in a future PR. We can still avoid the `strcpy` in the constructor and not save the size instead, that's still a good PR. Changing UL to use fat pointers can be investigated in the future.

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

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