Почему ява так себя ведёт?

Кто-нибудь может объяснить логику сабжа?
Игра идеально идёт при выделенных 1 гб озу
Если выделить ей, к примеру, 2 гб, то игра будет потреблять их в полной мере, но при этом будет работать также (И даже хуже, чем в прошлом случае)
Почему так?
 
Может ты даешь ей два гига, когда у тебя всего полтора-два?
Я даю игре два гига, когда у меня восемь
Но она при этом начинает работать хуже, + потребляет в два раза больше данного значения (Два игра, два сама ява)
 
7,099
324
1,509
Плохо настроил сборщик мусора. Он видит ,что памяти много свободной и редко делает очистку
 
1,111
47
420
Хей, бро, не тупи. Память это не нечто эфимерное так то. Если у тебя в куче 5 объектов по 16 байт, это вовсе не говорит, что ос думает, что куча занимает 80 байт. Нет. Ос думает, что куча занимает столько памяти, сколько жава запросила. Дальше оське уже все равно на то что там происходит.
Почему жава жрет больше чем ей нужно? Очень просто. Выделение памяти это занятие не из быстрых. Хотя даже не само выделение, а, скорее, возможный последующий перенос массива из одного куска памяти в другой. Таким образом выходит, что иметь заранее преаллоцированую кучу куда эффективней, чем вечно освобождать и забирать память. В реалиях жавы считается хорошим тоном ставить одинаковые xmx и xms.
Возможно, с точки зрения калькуляторов это варварство, но жава делается для энтерпрайза, и за счет таких вот фич у нее работа с памятью одна из самых эффективных. Тот же го проигрывает капитально, чему я удивился не слабо в свое время.
 
1,111
47
420
Еще, кстати, не стоит забывать про само определение Xmx. Xmx - это максимальный размер КУЧИ. Это НЕ тотальное и нерушимое максимальное число байтиков, занимаемое процессом.
 
Плохо настроил сборщик мусора. Он видит ,что памяти много свободной и редко делает очистку
А что можно кроме -Xincgc вписать ещё?
Хей, бро, не тупи. Память это не нечто эфимерное так то. Если у тебя в куче 5 объектов по 16 байт, это вовсе не говорит, что ос думает, что куча занимает 80 байт. Нет. Ос думает, что куча занимает столько памяти, сколько жава запросила. Дальше оське уже все равно на то что там происходит.
Почему жава жрет больше чем ей нужно? Очень просто. Выделение памяти это занятие не из быстрых. Хотя даже не само выделение, а, скорее, возможный последующий перенос массива из одного куска памяти в другой. Таким образом выходит, что иметь заранее преаллоцированую кучу куда эффективней, чем вечно освобождать и забирать память. В реалиях жавы считается хорошим тоном ставить одинаковые xmx и xms.
Возможно, с точки зрения калькуляторов это варварство, но жава делается для энтерпрайза, и за счет таких вот фич у нее работа с памятью одна из самых эффективных. Тот же го проигрывает капитально, чему я удивился не слабо в свое время.
Еще, кстати, не стоит забывать про само определение Xmx. Xmx - это максимальный размер КУЧИ. Это НЕ тотальное и нерушимое максимальное число байтиков, занимаемое процессом.
Допёрло наконец
 
7,099
324
1,509
1,111
47
420
Т.е. для сервера лучше очищать память редко и большими кусками?
Имхо, идеальный вариант развития событий для жавы - это выделение ей одного огромного и постоянного куска памяти. Не вижу смысла отдавать память обратно оське.
 

CumingSoon

Местный стендапер
1,634
12
269
редко и большими кусками
По идее, да. Очищение вполне себе шустрое. Куда медленнее дефрагментировать. И дефрагментировать большое количество данных значительно дольше, чем маленькое
 
7,099
324
1,509
отдавать память обратно оське
Я имел ввиду работу сборщика мусора. Он разве отдает память оське? Он же просто чистит неиспользуемые объекты и дефрагментирует
 
Сверху