8340363: Tag-specific default decorators for UnifiedLogging

[coleen.phillimore at oracle.com]

Thank you for this limited but creative solution to the problem that we 
don't want decorators on some logging tag combinations.  This would be 
useful for some runtime tracing that we didn't convert to UL because we 
don't want decorators, e.g. -XX:+PrintInterpreter.

I like it a lot.
Coleen

On 9/30/24 5:32 AM, Anton Seoane Ampudia wrote:
>
> Yes. I agree on the original idea being more flexible, but it has the 
> risk of defaults being not completely agreed on and “infecting” some 
> people’s expected output. The (only) use case that has driven this has 
> been the “no decorators” default, which is what I am tentatively 
> restricting the original idea to.
>
> As Roberto Castañeda mentioned before, yes, this would be equivalent 
> to -Xlog:tags::none, but a bit more ergonomic and convenient 
> considering that with the upcoming compiler migration to UL many of 
> these undecorated output cases will appear.
>
> Antón
>
> *From: *hotspot-dev <hotspot-dev-retn at openjdk.org> on behalf of David 
> Holmes <david.holmes at oracle.com>
> *Date: *Monday, 30 September 2024 at 02:39
> *To: *hotspot-dev at openjdk.org <hotspot-dev at openjdk.org>
> *Subject: *Re: 8340363: Tag-specific default decorators for UnifiedLogging
>
> Hi Anton,
>
> Thanks for bringing this up for general discussion outside the PR.
>
> Just to be clear for other readers, decorators are associated with a
> given log output device.
>
> On 27/09/2024 7:07 pm, Anton Seoane Ampudia wrote:
> > Hi all,
> >
> > Currently, the Unified Logging framework defaults to three decorators
> > (uptime, level, tags) whenever the user does not specify otherwise
> > through -Xlog. This resultssometimes 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/ <https://github.com/openjdk/>
> > jdk/pull/20988 <https://github.com/openjdk/jdk/pull/20988 
> <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).
>
> So to be clear, is the proposal now to just drop the default decorators,
> rather than allowing them to be replaced with alternate defaults? If
> that is the case then it is the same as writing:
>
> -Xlog:A+B::none
>
> and I don't really see much value in that. But I wouldn't oppose it.
>
> Allowing new defaults gives more flexibility - but obviously the
> developers using the specific tag combinations have to agree on what
> defaults to set.
>
> Thanks,
> David
> -----
>
> > 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/20240930/be16f0e8/attachment.htm>