Hi all,
I agree with Marcus here. Adding more levels below the Trace level seems
odd.
I interpret Marcus' suggestion 2) as that there would be for example a
log_develop_trace() macro that does nothing in product builds and that
calls log_trace() in debug builds. Similarly for info and debug.
To me that seems like a reasonable approach. But I do see the problem
that Marcus mentions. That it will be hard to distinguish develop
logging from normal logging in the output.
So far it's been enough for me with the single Develop level. Can you
give an example of a use case where the different develop levels are needed?
Thanks,
Bengt
On 2015-11-11 15:01, Marcus Larsson wrote:
Hi,
I don't think this is the right approach for this problem.
These new develop levels are introduced as even finer levels than the
trace, but have names that somewhat say otherwise.
For example, develop_info is finer than trace, but it isn't
unreasonable to expect that develop_info actually shares verbosity
with the regular info level.
I see two ways to look at this:
1) develop is a level, which is so verbose/expensive that it is not
possible to include it in the product (current implementation).
The following levels are used: error, warning, info, debug, trace and
develop. There is no concept of levels for the develop only logging
(it IS the level).
Selecting/distinguishing different logging on develop level is done by
using tags.
2) There is no concept of a develop level, either the logging is
included in product or it isn't (compare to using #ifdefs around the
logging calls).
Development-only logging is orthogonal to the regular log levels, i.e.
some log_info calls should only be made in non-product builds
(log_develop_info),
but should still follow the regular log level system (as all other
logging does) and use the info level.
The following levels are used: error, warning, info, debug, trace, and
convenience macros are used to strip develop-logging from non-product
builds.
The downside of this approach is that it becomes harder to distinguish
what is logged only in non-product builds and what is always logged.
Depending on if the build is non-product or not one can get different
output for "-Xlog".
The current proposal mixes these two approaches and adds develop
"levels" that are all finer than trace, which is confusing.
In my opinion, there should be no reason to require multiple levels
for non-product logging. I would assume all develop level logging to
be very specific, i.e. have a very specific tagset,
and require no support for selection/separation using log levels. If
it does, then I would argue for that the logging is missing some
classifying log tag that could be used instead of a level.
The logging has already been classified as verbose/expensive, why
classify it further on a level scale?
Thanks,
Marcus
On 2015-11-11 00:13, Coleen Phillimore wrote:
I think this looks good. I added serviceability-dev to the mailing
list.
Coleen
On 11/10/15 2:18 PM, Rachel Protacio wrote:
Good point. I have changed Develop to DevelopInfo. I think it's
better to maintain the same levels of levels on the develop side so
that the logging can just shift laterally to non-product, as it were.
And yes, they are specified as -Xlog:<tag>=develop_debug
Updated webrev: http://cr.openjdk.java.net/~rprotacio/8142366.01/
I re-tested with logging jtreg tests and ExecuteInternalVMTests
test, and for anyone who was curious (namely Max who had the good
idea for me to check), the debug levels do correctly "nest" with
more verbose ones printing out the less verbose and product mode
logging as well.
Thanks,
Rachel
On 11/9/2015 6:05 PM, Coleen Phillimore wrote:
Hi Rachel,
I sort of thought DevelopDebug would replace plain Develop, and
DevelopTrace would be additional lower level. Maybe plain Develop
should be DevelopInfo then?
Another question - how do you specify these levels? Is it
-Xlog:itables=develop_debug ?
Thanks,
Coleen
On 11/9/15 5:55 PM, Rachel Protacio wrote:
Hello,
Please see my small changeset to add two develop levels to UL.
Summary: This adds develop (that is, non-product) logging levels
to the Unified Logging framework in order to support performance,
footprint, and usefulness-of-output considerations while
maintaining the ability for the user to specify levels of
verbosity, i.e. default, "debug," and "trace" levels.
Open webrev: http://cr.openjdk.java.net/~rprotacio/8142366/
Bug: https://bugs.openjdk.java.net/browse/JDK-8142366
I tested the added levels locally with sample log messages to
ensure proper functioning. When I convert future tags to logging
with these levels, those tags will have their own tests and
inherently exercise the added levels.
Thank you,
Rachel
