8340363: Tag-specific default decorators for UnifiedLogging

[Anton Seoane Ampudia]

Hi all,

Currently, the Unified Logging framework defaults to three decorators (uptime, level, tags) whenever the user does not specify otherwise through -Xlog. This results sometimes inconvenient when specific users with some predefined needs do not want those tags. For example, C2 developers would rather not see those defaults in cases such as jit+inlining, but also do not want to specify so every time they run -Xlog.

One solution for this is found in this PR: https://github.com/openjdk/jdk/pull/20988. It can be considered as a “flavoured” version of the existing default decorators and in no way it will override anything user-specified. Also, decorators will still be consistent throughout an output device (i.e., no different decorators “mixed in”).

However, upon recent talks with different teams this approach may be too flexible/powerful. The ability of specifying LogSelection-bound default decorators may result in a situation where defaults for A+B and C+D have been specified, and a user selects -Xlog:A+B,C+D. In that case, the union of the prespecified defaults is taken, which may not be what the end user wants (and might result in too many decorators).

Actually, the main use case for this that I know as of now is C2 developers and the wish to not see decorators for some defined log selections. With this in mind, I have reduced the original idea to a feature where only the default decorators are not shown if we get a positive match with a prespecified list throughout the entire user log selection list (i.e.:

  *   If there is a default for A+B and the user specifies -Xlog:A+B,C+D, he will still get the default decorators
  *   If there is a default for A+B and the user specifies -Xlog:A+B, no default decorators will be supplied).

Before scraping the original idea and moving on with this one (which will not change anything as it is right now, except for the really specific uses like C2 jit+inlining that may be decided), I wanted to get a broader idea of people’s opinions on this, as well as other use cases for this behaviour.

Many thanks,
Antón
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20240927/929b8a7f/attachment.htm>