Details

    • Author:
      Jon Masamitsu
    • JEP Type:
      Feature
    • Exposure:
      Open
    • Subcomponent:
      gc
    • Scope:
      JDK
    • Discussion:
      hotspot dash gc dash dev at openjdk dot java dot net
    • Effort:
      L
    • Duration:
      L
    • Alert Status:
       Green
    • JEP Number:
      271

      Description

      Summary

      Reimplement GC logging using the unified JVM logging framework introduced in JEP 158.

      Non-Goals

      It is not a goal to ensure that current GC log parsers work without change on the new GC logs.

      Not all log entries will necessarily be reproduced in the new logging format.

      Description

      Reimplement GC logging in a manner that is as consistent as is reasonable with the current GC logging format. There will, of necessity, be some difference between the new and the old formats.

      The "gc" Tag

      The idea is that -Xlog:gc (only log on the "gc" tag at info level) should be similar to what -XX:+PrintGC did, which was printing one line per GC. This means that log_info(gc)("message") should be used very carefully. Don't log at the info level on just the "gc" tag unless it is the one message that should be printed per GC.

      It is fine to log at the info level using the "gc" tag if it is combined with other tags. For example:

      log_info(gc, heap, ergo)("Heap expanded");

      The idea here is that -Xlog:gc should be somewhat similar to what you used to get with -XX:+PrintGCDetails. But this mapping is not as strict as the mapping from -Xlog:gc to -XX:+PrintGC. The rule for -XX:+PrintGC was pretty clear: one line per GC. The rule for -XX:+PrintGCDetails has never been very clear. So, some -XX:+PrintGCDetials logging may be mapped to several tags and some may just be mapped to the debug level for the "gc" tag.

      All GC-related logging should use the "gc" tag. Most logging should not use just the "gc" tag but, rather, combine it with other tags as appropriate.

      There are also border-line cases where it is unclear whether "gc" is the appropriate tag, for example in allocation code. Most of these cases should probably not use the "gc" tag.

      Other Tags

      There are many other tags besides "gc". Some of them map pretty cleanly to old flags. PrintAdaptiveSizePolicy, for example, is more or less mapped to the "ergo" tag (in combination with the "gc" tag and potentially other tags).

      Verbose

      Most logging that was guarded by the Verbose flag (a develop flag) should be mapped to the trace level. The exception is if it is very expensive logging from a performance perspective, in which case it is mapped to the develop level.

      Prefix

      The prefix support in the unified logging framework is used to add the GC id to GC log messages. The GC id is only interesting for logging that happens during a GC. Since the prefixes are defined for a particular tag set, i.e., a combination of tags, it is necessary to make sure that logging that occurs between GCs do not use the same tag set as logging that is done during GCs.

      Dynamic Configuration

      Some logging requires that data has been collected at an earlier state. The unified logging framework allows for all logging to be dynamically turned on and off using jcmd. This means that for logging that relies on previously-collected data it is not enough to check whether logging is enabled; there must also be checks in place to check that the data is available.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                sjohanss Stefan Johansson
                Reporter:
                jmasa Jon Masamitsu (Inactive)
                Owner:
                Bengt Rutisson (Inactive)
                Reviewed By:
                Mikael Vidstedt
                Endorsed By:
                Mikael Vidstedt
              • Votes:
                0 Vote for this issue
                Watchers:
                10 Start watching this issue

                Dates

                • Due:
                  Created:
                  Updated:
                  Resolved:
                  Integration Due: