RFR [S]: 8227527: LogDecorations should lazily resolve host name
Claes Redestad
claes.redestad at oracle.com
Wed Jul 10 19:30:03 UTC 2019
Hi,
On 2019-07-10 20:02, Lois Foltan wrote:
> On 7/10/2019 10:56 AM, Claes Redestad wrote:
>> Hi,
>>
>> reportedly the uname syscall taken to initialize logDecorations can
>> carry a small but measurable startup cost on some systems/platforms, so
>> the not-used-by-default _host_name should be lazily initialized.
>>
>> Webrev: http://cr.openjdk.java.net/~redestad/8227527/open.00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227527
>> Testing: t1-3
>>
>> Thanks!
>>
>> /Claes
> Hi Claes,
>
> This looks good.
thanks, Lois!
> One minor comment:
>
> share/logging/logDecorations.cpp:
> - line #53 - 55: I assume that if old_value is not equal to NULL implies
> that host_name and old_value should give you the same host name string,
> correct?
> You could always add an assert in the if statement if you think
> warranted, "assert(strcmp(old_value, host_name) != 0, "comment...");
In most cases they'll be the same, yes, but such an assert could trigger
if the host name is being changed and 2 or more threads are racing to
init _host_name. Extremely unlikely, but if it ever happened I think we
should just use the installed value. This isn't very different from the
behavior today (host name changes are ignored), while observing a sudden
host name change during execution could be very surprising for various
log parsers.
Does that sound reasonable?
/Claes
More information about the hotspot-runtime-dev
mailing list