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

Lois Foltan lois.foltan at oracle.com
Wed Jul 10 20:29:13 UTC 2019



On 7/10/2019 3:30 PM, Claes Redestad wrote:
> 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?

Yes, thank you!
Lois

>
> /Claes



More information about the hotspot-runtime-dev mailing list