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:
java.util.Date with only fastTime: 24 bytes
java.util.Date with fastTime and cdate: 120 bytes