High memory consumption about ical4j

[benfortuna]

Yes, because this issue is very old I think it may not apply to the current develop branch of ical4j.

But if you do find this is still an issue feel free to raise a new ticket or we can reopen this one.

[jamieb22]

[nealeu]

Hi,
It's also worth noting the ZoneInfo line which is related. If you check duplicates you'll find lots of ZoneInfo object duplicates (in our case all Etc/GMT). These may in our case occur due to hydration of objects from either Hibernate or EhCache, and could be deduplicated within DateTime.setTimezone().

@benfortuna what do you think about some work to deduplicate some of these. In our case we have 250k ZoneInfo objects taking up 4% of memory.

[benfortuna]

Hi nealeu,

I suspect the ZoneInfo instances are referenced by java.util.Date instances, or possibly also DateFormat instances, so hopefully they should de-dupe if we optimise the dates. In fact I think the whole problem will go away, or at least change, if we implement the new Java date/time API. But if there are some easy fixes to implement beforehand I will also try to do that.

[nealeu]

Hi @benfortuna,
Yes, I believe they are. I may be able to take a more detailed look this Friday, and possibly put in a pull request.

[nealeu]

Hi Ben,
I'm having a look at this now. I suspect what you're saying about the new API is that it's immutable, and therefore doesn't have things like:

public static TimeZone getDefault() {
    return (TimeZone) getDefaultRef().clone();
}

[nealeu]

Looking at where TimeZone instances get created, most are where no zone is supplied in calls to things like DateTime, and therefore resetTimeZone() is called, which does a .clone().

An example is at DateTime.setTimeZone(TimeZone).

It looks as though we could supply a default singleton into that call, with setID and setRawOffset overridden defensively to prevent modification. I'll give this a go locally.

[benfortuna]

older versions now in maintenance mode only

[nealeu]

@benfortuna Thanks for updating. I can see v4 is a significant change from 3. Are you expecting this to have been resolved in that version?
Thanks.

[nealeu]

I dove in and I think I have the answer.

This commit shifts to being able to switch to UTC by default (which fits our usage) and therefore uses a singleton.

c754e47#diff-a393647dc44579901b89524b7fe7a4c680cb4506ed868f8ae23305a3645fdba9