TCPIP
Silver Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору vndovr Цитата: что понимается под подкачкой | Я имел в виду кучу. Наверное, это неправильно... Даже скажем так в корне неправильно. Сорри. Цитата: Эти параметры задаю начальное количество памяти доступное приложению и максимальное | Ну, так это, если я правильно понимаю, растяжимое понятие. Иначе было бы только 2 параметра Xms96m (start) и Xmx (max). А вот для чего остальные? Цитата: Xmn jdk specific - насколько я помню влияет на то как работает GC. | Да в том-то и дело, что судя по всему - нет. Цитата: Один из наиболее полезных параметров здесь -Xmx - попробовать его увеличить | Сделал. Помоголо но не до конца. Цитата: Возник вопрос - а с чего предположение что проблемы именно с памятью? | Именно с того, что сборщик мусора, до того, как я увеличил максимальный размер кучи, работал, похоже, непрерывно - процессор простоянно загружен. Сейчас получше, но все равно - загрузка процессора адская - в среднем процентов 15%. Это если приложение работает в фоне. Если же переключать в нем элементы интерфейса вообще часто 100% и по нескольку секунд. Время сборки мусора операцией Copy сейчас составляет ~20 с.; операцией MarkSweepCompact ~ в 3 раза больше. Время компиляции ~8c на ~5000 загруженных классов. Собственно, хочется совета, нечто вроде выдержки отсюда... Интересная статья, но для человека далекого от JAVA, немного перебор. Особливо, в моем простом случае. Теперь почему именно память. Похоже в Azureus ооочень большие проблемы с GUI, да и не только. Частенько по дампам видно, что многие функции UI (библиотека SWT) принимали null на вход. Соответственно, частенько при закрытии диалогового окна, объект не закрывается, пока, скажем, не открыть главное окно. И прочее в том же духе. То есть у приложения проблемы с памятью, надо ему помочь, ибо JVM сама не может. | Всего записей: 4667 | Зарегистр. 31-01-2003 | Отправлено: 03:41 06-11-2008 | Исправлено: TCPIP, 03:48 06-11-2008 |
|