Конфигурация на основе весенних аннотаций - слишком высокое потребление памяти?

Когда я заметил сумасшедшее использование ОЗУ в моем клиентском приложении (на основе Swing), я начал изучать его, и похоже, что это как-то связано с конфигурацией на основе аннотаций в Spring. Как вы увидите в моих правках ниже, я понял, что это происходит только на 64-битной JVM.

См. следующий тестовый код:

конфигурация на основе XML

<beans ....>
     <bean id="xmlConfigTest" class="at.test.XmlConfigTest" />
</beans>

public class XmlConfigTest extends JFrame {
    public static void main(String[] args) {
        ApplicationContext ctx = new ClassPathXmlApplicationContext("config/applicationContext.xml");
        XmlConfigTest frame = (XmlConfigTest) ctx.getBean("xmlConfigTest");
        frame.setDefaultCloseOperation(EXIT_ON_CLOSE);
        frame.setVisible(true);
    }
}

Использует около 32 МБ памяти, что мне кажется нормальным.

Теперь то же самое с настройкой на основе аннотаций:

@Service
public class AnnotationConfigTestFrame extends JFrame {
    public static void main(String[] args) throws InterruptedException {
        ApplicationContext ctx = new AnnotationConfigApplicationContext("at.test");

        AnnotationConfigTestFrame frame = (AnnotationConfigTestFrame) ctx
            .getBean("annotationConfigTestFrame");
       frame.setDefaultCloseOperation(EXIT_ON_CLOSE);
       frame.setVisible(true);
    }
}

Мало того, что открытие фрейма занимает заметно больше времени, так еще и потребление памяти взлетает до 160 МБ памяти при запуске, а затем выравнивается примерно до 152 МБ, что мне кажется очень высоким. И помните, это только самый простой случай, клиентское приложение, которое я разрабатываю, уже потребляет более 400 МБ, что слишком много для старых машин.

У кого-нибудь есть объяснение такому поведению? Я не понимаю..

(Кстати, здесь используется 3.1.1.RELEASE.)

edit* Как было предложено axtavt, я также попытался построить AnnotationConfigApplicationContext непосредственно с тестовым классом в качестве аргумента, так что сканирование путей к классам не требуется. К сожалению, ничего не изменилось в потреблении памяти.

изменение 2 удалено, см. изменение 3

edit 3 Сейчас я тестировал на той же машине (64-разрядная версия Windows 7) как с 32-разрядной, так и с 64-разрядной JVM и тестовыми программами, указанными выше. Вот результаты:

конфигурация на основе xml:

32-Bit JVM: 16MB
64-Bit JVM: 31MB

конфигурация на основе аннотации:

32-Bit JVM: 17MB
64-Bit JVM: 160MB

Таким образом, на 32-битной JVM обе программы близки, чего я и ожидал. Однако на 64-битной версии все по-другому. Даже первая программа использует вдвое больше памяти на 64-битной, что уже кажется лишним. Тем не менее, это не имеет ничего против второй программы, которая использует почти в 10 раз больше памяти на 64-битной системе.

редактировать 4 Теперь протестировано и под Ubuntu -> тот же эффект. Однако до сих пор не знаю, почему это происходит. Это действительно нарушение сделки для меня