java.util.Date uses lots of heap space after toString() is called
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().
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:
Note that this solution relies on the internal semantics of the java.util.Date object. We may need a different solution in the future if the code for java.util.Date changes or we may not need this workaround at all if they, for instance, stop using the cdate field.
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