RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v2]

Thomas Stuefe stuefe at openjdk.org
Thu Sep 8 11:32:46 UTC 2022


On Thu, 8 Sep 2022 00:32:59 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> I prefer trailing 0 because `AsyncLogMessage::message()` can be treated as a valid c-string and pass to LogFileStreamOutput. If so, `len` is optional indeed. The benefit of `len` is that we can iterate buffer faster. We will have O(1) time-complexity instead of O(len) in `Buffer::Iterator::next() `
>> 
>> I see your point. It's more elegant to use `implicit` message. The reason I need to handle `msg= nullptr` is that flushing Token uses it. I can replace it with "" instead.
>
> I update to use in-place new for AsyncLogMessage objects. For safety, I change AsyncLogMessage to a nested class and rename it to 'Message'. It's private so it's not accessible by outside.
> 
> Previously, we had at least one extra copy of `LogDecorations`. Now it aligns with c-str message. We materialize them only in constructor. Because we have to support asynchronous execution, this is optimal.

> I prefer trailing 0 because `AsyncLogMessage::message()` can be treated as a valid c-string and pass to LogFileStreamOutput. If so, `len` is optional indeed. The benefit of `len` is that we can iterate buffer faster. We will have O(1) time-complexity instead of O(len) in `Buffer::Iterator::next() `

That's what I meant. Keep the trailing '\0' but for performance reasons cache length too in whatever size is sufficient. I see you kept using strlen. Now you do two strlen + align calls, one in push_back, one on iteration.

> 
> I see your point. It's more elegant to use `implicit` message. The reason I need to handle `msg= nullptr` is that flushing Token uses it. I can replace it with "" instead.

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

PR: https://git.openjdk.org/jdk/pull/10092


More information about the hotspot-runtime-dev mailing list