Uploaded image for project: 'OpenNMS'
  1. OpenNMS
  2. NMS-9091

java.util.Date uses lots of heap space after toString() is called

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Major
    • Resolution: Fixed
    • 19.0.0
    • 19.1.0
    • Eventd
    • Security Level: Default (Default Security Scheme)
    • None
    • Horizon - March 29th

    Description

      In a recent heap dump from a system that OOMd due to Eventd backlog, the largest consumer of RAM was java.util.Date#cdate. This is a hidden calendar field that is only used in certain circumstances but notably is populated when you call java.util.Date.toString().

      http://stackoverflow.com/a/25599891

      It looks like we need to police spots in Eventd (and maybe other places in the code) where we are calling Date.toString() and only call that method on a copy of a date. Otherwise, if the Date ends up in any sort of long-lived collection, it can take up a lot of space:

      http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/util/Date.java

      java.util.Date with only fastTime: 24 bytes
      java.util.Date with fastTime and cdate: 120 bytes

      Attachments

        Activity

          People

            seth Seth Leger
            seth Seth Leger
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: