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

JFR generate same symbol ID for different symbols in 8U

    XMLWordPrintable

    Details

    • Subcomponent:
      jfr
    • Introduced In Version:
    • Resolved In Build:
      b02
    • CPU:
      generic
    • OS:
      generic

      Description

      This cause wrong method/field name signature when parsing and print JFR records in dump file. This can be easily reproduced with CDS on.

      Reproduce with lasted 8u build with SPECJvm2008 (tested on X86-64 )
      1. java -Xshare:dump -version
      2. java -Xshare:on -XX:StartFlightRecording=dumponexit,settings=profile,filename=my.jfr -jar SPECjvm2008.jar -ikv -ict crypto.signverify -wt 30s -it 30s
      3. iterate JFR records and dump events, has high possiblity crash
      java -cp . Parser my.jfr >tmp // check attached Parser.java
      Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String index out of range: -2
              at java.lang.String.substring(String.java:1967)
              at jdk.jfr.internal.tool.PrettyWriter.formatMethod(PrettyWriter.java:461)
              at jdk.jfr.internal.tool.PrettyWriter.printJavaFrame(PrettyWriter.java:445)
              at jdk.jfr.internal.tool.PrettyWriter.printValue(PrettyWriter.java:306)
              at jdk.jfr.internal.tool.PrettyWriter.printStackTrace(PrettyWriter.java:242)
              at jdk.jfr.internal.tool.PrettyWriter.print(PrettyWriter.java:221)
              at jdk.jfr.consumer.RecordedObject.toString(RecordedObject.java:883)
              at Parser.main(Parser.java:15)

      This happens because
      1. When CDS is on, it saves symbols in shared archive with their computed _identity_hash.
      2. In second run, Symbols from archive and from current java process have large chances to have same identity_hash. Because symbol.identity_hash is calculated with fixed initial seed and algorithm in os::random().
      3. JfrSymbolId::equals always return true when hashcode is true. So JfrSymbolId::mark(const Symbol* symbol) will return same id for different symbols.

      JDK11 doesn't have this issue
      1. JDK11 Symbol_identity_hash algorithm is different, it computes from _identity_hash, self address, length and first two chars.
      2. When smbol has same hashcode, JfrSymbolId::on_equals return false if Symbol address is different.

      Proposed fix will check if symbol is address is same in JfrSymbolId::equals(const char* query, uintptr_t hash, const CStringEntry* entry), this is same with JDK11.

      This will not cause JFR file bigger because different symbols have same chars still have different _identity_hash. They have no chance have same hashcode in JFR symbol_id table.

        Attachments

          Activity

            People

            Assignee:
            hshi Hui Shi
            Reporter:
            hshi Hui Shi
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: