vndovr
Цитата:
Я имел в виду кучу. Наверное, это неправильно... Даже скажем так в корне неправильно. Сорри.
Цитата:
Ну, так это, если я правильно понимаю, растяжимое понятие. Иначе было бы только 2 параметра Xms96m (start) и Xmx (max). А вот для чего остальные?
Цитата:
Да в том-то и дело, что судя по всему - нет.
Цитата:
Сделал. Помоголо но не до конца.
Цитата:
Именно с того, что сборщик мусора, до того, как я увеличил максимальный размер кучи, работал, похоже, непрерывно - процессор простоянно загружен.
Сейчас получше, но все равно - загрузка процессора адская - в среднем процентов 15%. Это если приложение работает в фоне. Если же переключать в нем элементы интерфейса вообще часто 100% и по нескольку секунд.
Время сборки мусора операцией Copy сейчас составляет ~20 с.; операцией MarkSweepCompact ~ в 3 раза больше.
Время компиляции ~8c на ~5000 загруженных классов.
Собственно, хочется совета, нечто вроде выдержки отсюда...
Интересная статья, но для человека далекого от JAVA, немного перебор. Особливо, в моем простом случае.
Теперь почему именно память. Похоже в Azureus ооочень большие проблемы с GUI, да и не только. Частенько по дампам видно, что многие функции UI (библиотека SWT) принимали null на вход. Соответственно, частенько при закрытии диалогового окна, объект не закрывается, пока, скажем, не открыть главное окно. И прочее в том же духе.
То есть у приложения проблемы с памятью, надо ему помочь, ибо JVM сама не может.
Цитата:
что понимается под подкачкой
Я имел в виду кучу. Наверное, это неправильно... Даже скажем так в корне неправильно. Сорри.
Цитата:
Эти параметры задаю начальное количество памяти доступное приложению и максимальное
Ну, так это, если я правильно понимаю, растяжимое понятие. Иначе было бы только 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 сама не может.