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