Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8276642

Enable 32 bit object identifiers when heap dumping compressed oops

    XMLWordPrintable

    Details

    • Type: CSR
    • Status: Draft
    • Priority: P4
    • Resolution: Unresolved
    • Fix Version/s: tbd
    • Component/s: hotspot
    • Labels:
      None
    • Subcomponent:
      svc

      Description

      Summary

      With help of a command line option, give the user the possibility to let the VM try to enable 32 bit object identifiers when heap dumping compressed oops.

      Problem

      Today, the identifiers (of UTF8 strings, objects, stack traces, etc) in heap dumps are always using the native pointer size as the size for identifiers. When dumping heaps with compressed oops, most identifiers can be represented by 32 bit values. If we instead would store them as 32 bit identifiers, quite a lot of space would be saved.

      One caveat is that the identifier size for oops, must be the same as for other "things". So if we dump compressed oops, we must also use 32 bit identifiers for Symbols and JNI handles. If we have too many symbols or handles, we will fallback to 64 bit identifier size. In the current code, both Symbols and JNI handles are identified by their pointer values.

      Solution

      The proposed solution is adding a new command line flag -XX:+HeapDumpCompressedIdentifiers that is false by default. When the user enables HeapDumpCompressedIdentifiers, we will do some extra actions when writing a heap dump:

      1. Count Symbols and JNI handles, if they fit 32 bit, dump with "compressed identifiers"
      2. When dumping with "compressed identifiers":
        • Rename all Symbols by first adding them to an array, sort the array, and use the 32 bit index of the symbol in the array as new identifier.
        • Rename all JNI handles when dumping them by just using a counter. The JNI handle is never referenced from other parts of the dump, so no need to keep a rename table.

      An alternative solution would be to have an external tool (outside of the JVM) do the compaction of identifiers. That solution would have the benefit of keeping the VM simpler and also enable compression even if compressed oops are not used, but less than 2^32 objects are in the heap.

      However, such a tool would use extra memory, would work with temporary files, and would make the usage much harder for the user, especially in memory limited containers.

      Specification

      diff --git a/src/hotspot/share/runtime/globals.hpp b/src/hotspot/share/runtime/globals.hpp
      index d98d0ad5226..bf748e24d50 100644
      --- a/src/hotspot/share/runtime/globals.hpp
      +++ b/src/hotspot/share/runtime/globals.hpp
      @@ -546,6 +546,9 @@ const intx ObjectAlignmentInBytes = 8;
                 "compression. Otherwise the level must be between 1 and 9.")      \
                 range(0, 9)                                                       \
                                                                                   \
      +  product(bool, HeapDumpCompressedIdentifiers, false,                       \
      +          "Try to use 32 bit identifiers in heap dumps")                    \
      +                                                                            \
         product(ccstr, NativeMemoryTracking, "off",                               \
                 "Native memory tracking options")                                 \
                                                                                   \

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              lkorinth Leo Korinth
              Reporter:
              lkorinth Leo Korinth
              Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated: