RFR (L): 8046148: JEP 158 Unified JVM Logging

[Marcus Larsson]

Hi Chris,

On 2015-09-07 18:05, Chris Newland wrote:
> Hi Marcus,
>
> Thanks for making this visible.
>
> Could you let me know how this will affect diagnostic VM logging such as
> LogCompilation and PrintAssembly?

The current patch doesn't modify any existing logging in the JVM, it 
only contains the new framework. However, follow-up JEPs and RFEs will 
convert existing logging to use the new framework, at which point you 
will see changes in how the logging works.

Given that the actual log messages are left untouched during migration, 
and the tty-print calls are just converted into log calls tagged 
appropriately, these changes should not significantly affect you. It is 
very dependent on the tags and level that are chosen to replace the 
previous flag-based configuration. There might be cases where additional 
log messages are merged into the same tag and level category as some 
previously flag-controlled output. For example, PrintAssembly-output 
might be merged with logging from some other logging flag. This really 
depends on the work to migrate to the new framework.

The method to enable logging will be changed from the individual flags 
to the unified log configuration scheme (-Xlog:... or by diagnostic 
commands, see the JEP for more info). Unless configured otherwise, the 
new log framework prefixes the log messages with decorators like uptime, 
level and tags (these are the default decorators).

>
> Once implemented, will the current output formats still be available?

Currently there is no specific support for XML output in the unified 
logging framework. Output can be directed either to stdout, stderr or 
plain text files. I'm not entirely sure how the migration of the XML 
logging will be done. Perhaps it will be preceded by an RFE to add 
better support for XML outputs in the unified logging framework, or it 
might just be treated as a regular text file.

Thanks,
Marcus

>
> Disclosure: I'm the author of a log processing tool (JITWatch [1]) that
> consumes LogCompilation, PrintAssembly, and TraceClassLoading.
>
> I've had a cursory grep through the webrev and it doesn't seem to affect
> these but I'll apply the changes tonight and have a proper look.
>
> Thanks,
>
> Chris
>
> [1] https://github.com/AdoptOpenJDK/jitwatch
>
> On Mon, September 7, 2015 14:33, Marcus Larsson wrote:
>> Hi,
>>
>>
>> Please review the following patch adding the unified logging framework
>> to hotspot.
>>
>> JEP:
>> https://bugs.openjdk.java.net/browse/JDK-8046148
>>
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mlarsson/8046148/webrev.00/
>>
>>
>> See the JEP description for a general overview of the new feature. Below
>> are some notes on the implementation.
>>
>> The patch adds the new 'share/vm/logging' subdirectory containing the
>> unified logging framework. The main entry point is log.hpp, which contains
>> the necessary macros and definitions to use the framework.
>>
>> Log tags are defined/listed in logTag.hpp, and are passed as template
>> arguments to the Log class. Every combination of tags used in a log call
>> has a corresponding LogTagSet instance, which keeps a track of all the
>> outputs it should write the log message to (and their levels). Having tags
>> as template arguments allows mapping directly from a set of tags to the
>> LogTagSet instance, which means that the overhead for disabled
>> logging should be low. Currently each log message can be tagged with up to
>> 5 tags, but this can be increased if ever required (and with C++11's
>> variadic templates the limit can be removed completely).
>>
>> The LogConfiguration class keeps track of configured outputs (stdout,
>> stderr, and possible file outputs). Configuration is done either by command
>> line arguments (-Xlog) or by DCMD. Both methods will in turn use the
>> LogConfiguration class to perform the parsing & configuration. This
>> configuration includes iterating over all LogTagSet instances and updating
>> them accordingly. The LogTagLevelExpression class is used to represent the
>> selection of tags and levels for a given configuration request (the
>> "what"-expression).
>>
>>
>> The LogDecorators class contains a selection of decorators. Instances of
>> this class is kept in LogTagSet to track what decorators to use (this is
>> the union of all decorators used by its outputs). Each log call will
>> create a LogDecorations instance (note: different classes), which will
>> contain the actual decoration strings for the log message. These
>> decorations are used for each output the tagset is set to log on, and are
>> then discarded.
>>
>> The LogPrefix class allows messages of specific sets of tags to be
>> prefixed. The prefix should supply a printf-style format with argument.
>> (This allows GC logging to prefix messages of certain tagsets with
>> GCId.) Prefixes are implemented using template specializations based on
>> the specified tags, with the general/unspecialized case giving an empty
>> prefix.
>>
>> The LogOutput class defines the interface for all types of log outputs.
>> LogFileStreamOutput corresponds to FILE* stream based log outputs.
>> LogFileOutput builds on this and adds the file management and log
>> rotation support.
>>
>> A simple jtreg test is included in this patch. Additional tests will be
>> added at a later stage.
>>
>> Thanks,
>> Marcus
>>
>>
>