RFR: 8341622: Tag-specific disabled default decorators for UnifiedLogging [v6]

[John R Rose]

On Wed, 9 Oct 2024 09:13:37 GMT, Antón Seoane <duke at openjdk.org> wrote:

>> Currently, the Unified Logging framework defaults to three decorators (uptime, level, tags) whenever the user does not specify otherwise through -Xlog. However, some specific logging cases do not need decorations, and manually having to disable them results in cumbersome extra input and loss of ergonomics. For example, C2 developers rarely need decorations, and having to manually specify this every time results inconvenient.
>> 
>> To address this, this PR enables the possibility of adding tag-specific disabling of default decorators to UL. These disables are in no way overriding user input -- they will only act whenever -Xlog has no decorators supplied and there is a positive match with the pre-specified defaults. Such a match is based on an inclusion rule: e.g. if -Xlog:jit+compilation is provided, a default for jit may be applied. Additionally, defaults may target a specific log level.
>> 
>> The original use case for this is related to C2 logging migration to UnifiedLogging, as currently no decorators are found in compiler logs and it would be expected to stay the same without the extra explicit removal every time via -Xlog. However, this would ease the migration of other logging that was initially deterred by this, such as -XX:+PrintInterpreter.
>> 
>> This PR is a simplification of the [8340363](https://bugs.openjdk.org/browse/JDK-8340363) (closed) ticket.
>
> Antón Seoane has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace LogDecorators::Decorator::NoDecorator with LogDecorators::None

For the compiler outputs which have no tags, what happens with (a) lines that begin with something like `[42] ` and (b) multi-line outputs?  In both cases a log parser could (on a bad day) struggle to interpret the UL records correctly.  I see that strict compatibility with existing compiler outputs can lead to additional parsing ambiguities, which will have to be dealt with at some point in the future.  (Is there a leading space?  I think not.  So a leading `[42]` could be a problem if it crops up.  Perhaps we need a targeted way to discriminate such things, such as injecting one leading space in some cases TBD.)  Note that I am not advocating, here, for an immediate solution for parsing ambiguities, but I do want us to track such issues.

Another side note, just FTR:  There is a third issue with UL output from compilation, which is the grouping of logically connected log outputs.  In the compiler logs we use XML nesting today for such logical grouping.  This grouping, in addition to unambiguous delimiting of decorations, is yet another use, by compilation logs, of a basic property of XML:  The syntax is not only somewhat readable, but also well defined.  I suppose if XML syntax is encapsulated in UL syntax, that would provide a parseable ("tool-friendly") solution.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21383#issuecomment-2407955314