RFR [S]: 8227527: LogDecorations should lazily resolve host name

Claes Redestad claes.redestad at oracle.com
Wed Jul 10 19:30:03 UTC 2019


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?


More information about the hotspot-runtime-dev mailing list