Собственно виртуальная память так и работает. Ничем принципиально Intel здесь не отличается от MF.Palych wrote:Вы этот подход пробовали на реальном приложении?zVlad wrote: Я не о том чтобы снижать потребление памяти в Java, пусть себе запрашивает, давайте ей виртуальную память, материализуйте ее по мере необходимости в реальной памяти, если реальной не достаточно выбрасывайте страницы во внешнюю память (делайте только это интеллектуально и строго по мере необходимости), введите понятие рабочего набора и введите механизм ограничения набора реальных страниц для разных... не знаю, контейнеров будет ли правильно сказать, или разных программ на апликэйшн сервере в соответствии с важностью тех или иных программ.
Экстраполяция опыта DB2 тут не уместна: память расходуется совершенно по-разному.
К тому же мне интересно как бы Вы определили важность того или иного компонента в он-лайновом приложении.
А главное - гуд лак, как говориться в выделение тех контейнеров и прочего внутри Java Heap.
Проблема в том что у java есть два существенных отличия от СУБД:
1. Garbage collector очень любит пробежать по спискам всех объектов в heap, то есть грубо говоря, по ВСЕЙ памяти (см п 2)
2. Если субд как правило работает с большими страницами, равными или кратными страницам виртуальной памяти, то движение проход списка в java (как впрочем и в .Net, C++ итд) представляет собой обращение к сильно разреженным pointers. То есть считаваются 8 bytes (next pointer) и далее прыгаем на неопределенное место. Для виртуальной памяти же неважно сколько считывается - 1 байт или вся страница - сразу ловим page fault и вперед за диском...