Relatively high memory footprint of Jollyday

[XSpielinbox]

Hi,
we have an endpoint in our server application where one can retrieve a calendar and one to check whether this is in sync with certain configurations the user made. The latter has a relatively high memory footprint, of which roughly 2/3 to 3/4 go to Jollyday.

As we had some memory issues, we were wondering whether we are properly reusing the HolidayManager instances or there is room for improving the memory usage of Jollyday.

Below is our code using Jollyday:
The service implementation class has the following snippet in it's constructor:

Set<String> supportedSet = HolidayManager.getSupportedCalendarCodes();
for (String code : supportedSet) {
    CalendarHierarchy hierarchy = HolidayManager.getInstance(ManagerParameters.create(code))
            .getCalendarHierarchy();
    recursiveHolidays(hierarchy, null, null);
}

It also defines two additional methods, that use it, of which only one uses HolidayManager:

private static boolean testHolidays(String[] countries, LocalDate date) {
    for (String holidayCode : countries) {
        String[] args = holidayCode.split("_");
        String[] adjArgs = Arrays.copyOfRange(args, 1, args.length);
        HolidayManager manager = HolidayManager.getInstance(ManagerParameters.create(args[0]));
        if (manager.isHoliday(date, adjArgs)) {
            return true;
        }
    }
    return false;
}

So in total it uses the classes CalendarHierarchy, HolidayManager and ManagerParameters.

The DTO class defines the following method using Jollyday:

public CalendarView view(boolean termsOnly) {
    [...]
    for (String holidayCode : holidaySet) {
        String[] args = holidayCode.split("_");
        String[] adjArgs = Arrays.copyOfRange(args, 1, args.length);
        HolidayManager manager = HolidayManager.getInstance(ManagerParameters.create(args[0]));
        Set<Holiday> holidaySet = manager.getHolidays(startDate, endDate, adjArgs);
        holidaySet.forEach(holiday -> {
            List<CalendarItem> existingList = calendar.getOrDefault(holiday.getDate(), new LinkedList<>());
            existingList.add(new CalendarItem(holiday.getDescription(), holidayCode));
            calendar.put(holiday.getDate(), existingList);
        });
    }
    return new CalendarView(calendar, this.holidaySet);
}

So in total it uses the classes Holiday, HolidayManager and ManagerParameters.

Is this the intended way to achieve this or should this be done differently to save memory resources? Are there memory improvements to be made upstream in Jollyday?

[derTobsch]

@XSpielinbox thanks for your reply. We need to look into that and add some tests.

What you can do to reduce the memory is to only create a HolidayManager for each country once and hold it in memory. This is how we do it in the Zeiterfassung https://github.com/urlaubsverwaltung/zeiterfassung/blob/main/src/main/java/de/focusshift/zeiterfassung/publicholiday/PublicHolidayConfiguration.java

[XSpielinbox]

Thank you for the reply. Even with the suggested change I, unfortunately, was unable to measure a memory difference. Could it be that using only jollyday with JAXB and the rest of the project with Jackson is the cause for this? (I sadly was unable to get it to work with the newly released jollyday-jackson yet, for a comparison.)

[derTobsch]

I digged into the code in the last couple of weeks and added tests and looked after memory leaks, but at the moment I did not find any. Could you maybe provide a heapdump or a Statistik of the number of classes that were created?

[derTobsch]

Btw I learned that the HolidayManagers will be cached and also the isHoliday Method too. The getHoliday method not as far as I can tell.

[XSpielinbox]

Sorry for my late reply.
Thank you for your investigation!

I am unable to reproduce the problem now. Therefore I am increasingly confused about my testing, but in a sense it is good that there are no memory problems (anymore?), I guess. : )

Anyway, here is an example heap-dump-difference of jollyday-classes of before and after logging in to our current application and interacting a bit with the calendar:


For context: the application was running for a longer period without interaction and this should have then completely captured the first interaction of a user with the application.

Interestingly again here, the before heapdump did not include any jollyday-classes, but the calculated difference is not just simply the later state:

Thanks again for your work!

[derTobsch]

Interesting. The two classes "ClassLoadingUtil" and "ResourceUtil" are now fully static, so in the 0.25.0 release there should not be any instances any more. The others seems plausible.

Thanks for sharing.