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