RFR: 8288298: Resolve multiline message parsing ambiguities in UL
David Holmes
dholmes at openjdk.org
Mon Oct 28 08:20:32 UTC 2024
On Mon, 28 Oct 2024 07:11:18 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:
>> src/hotspot/share/logging/logFileStreamOutput.cpp line 179:
>>
>>> 177: return 0;
>>> 178: }
>>> 179: ALLOW_C_FUNCTION(::memcpy, ::memcpy(dupstr, msg, msg_len + 1);)
>>
>> Why not use `os::strdup`?
>
> We already know the length of the string, so why use something that needs to find the length again?
>
> We shouldn't need the `ALLOW_C_FUNCTION` for memcpy however, the rest of the codebase doesn't use it. Raw malloc here is the good choice, as to avoid circular logging.
Good point. I was thinking more why break a strdup into the composite alloc + memcpy. And do we really want to avoid NMT here?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21712#discussion_r1818550835
More information about the hotspot-runtime-dev
mailing list