UL: logging before initialization?

[Marcus Larsson]

Hi,

On 2016-03-11 03:12, David Holmes wrote:
> Hi Thomas,
>
> Expanding to hotspot-dev as UL was not designed/built by the runtime 
> team.
>
> My comments below based on my limited understanding of UL.
>
> On 11/03/2016 2:25 AM, Thomas Stüfe wrote:
>> Hi all,
>>
>> I wanted to use UL to log some information from early OS 
>> initialization but
>> found that we initialize logging quite late. It is initialized way after
>> os::init() runs.
>
> There are various dependencies in the unified logging framework that 
> prevent it (or at least parts of it) from being used early eg:
> - argument parsing and log configuration
> - existence of current thread (for logStreams)

Currently, the framework can be used as soon as static initialization is 
done. This doesn't include the logStreams of course since they require 
resource allocations. The problem is as you say that there is no way to 
configure the logging before parsing the -Xlog command. This means up 
until that point the default configuration will apply, which means 
warnings and errors to stdout.

>
>> I also see that warnings and errors are printed unconditionally even
>> before, only log calls for levels <= info are quietly swallowed.
>
> Are those warnings/errors using UL? I suspect not.

They could be, since errors and warnings are enabled by default.

>
> Silent swallowing is not good though.
>
>> Would there be a way to move UL initialization and parsing of -Xlog
>> Arguments to an earlier point to be able to use logging in os::init()?
>
> I don't see how you could utilize tags and levels until after full 
> initialization of the logging system, so that would preclude using it 
> as early as os::init.

It is a possible solution I guess. I don't know how dependent argument 
parsing is on other initialization. There would always be some part of 
the initialization where you only have warning and error logging unless 
we do the parsing first thing during startup, which I assume will be 
impossible.

>
>> Or, if that is not possible, would there be a way to delay printing of
>> early logging calls to after logging initialization and then print 
>> them out
>> in one go? I think this would be not trivial though: one would have to
>> collect all logging output in memory somewhere - because we do not 
>> yet know
>> which tags are switched on - and then, once -Xlog is parsed, filter 
>> it by
>> tag before printing it out.
>
> Yeah that seems difficult/complex given the problem that the VM is in 
> the early stages of initialization
>
>> What do you think, would that be a worthwhile change? I am a bit unhappy
>> about how logging calls are quietly swallowed, so for any code which 
>> runs
>> at VM initialization, one always has to keep in mind that UL may not 
>> yet be
>> initialized.
>
> Not a new problem (adding more code during VM initialization) but one 
> that is getting more complicated :)

I think it would perhaps be worthwhile if there's demand for a bunch of 
info to trace level logging from startup code (before argument parsing).

Thanks,
Marcus

>
> Cheers,
> David
>
>> Kind Regards, Thomas
>>