В процессе работы кода (приложение и апплет - не важно) иногда появляется следующее сообщение:

Я так понимаю, что мне не хватает памяти. Вполне вероятно код не оптимальный, но всё же, как увеличить размер кучи?
Именно из кода.

Никак.

Ответ последовал быстро, но не порадовал.
Получается выход один? Исправлять код?

Можно поправить скрипт который запускает приложение.

Из кода, вызовом какого-либо метода - не знаю, думаю что нет такого добра в Java.
Вам нужно найти причину почему вылетает OOM exception...

При старте JVM  Вы можете передать переменные и значения, задающие поведение JVM. 

У меня был случай с Томкэтом, когда веб приложение отваливалось по OOM exception...
Изменили дефолтовое значение MaxPermSize - болезнь вылечилась.Пример:
JAVA_OPTS should be set to: “-Xss128k -server -Xms512m -Xmx512m -XX:MaxPermSize=256m“

Смотрите первоисточник...

ага, добавь -Xmx512m  (или больше) и будет тибе щасье 
запускай как то так 

java -jar -Xmx756m Test.jar

PS у меня недавно ant билдер вылетал, вот уж никогда бы не подумал. Пришлось добавлять параметры. Хотя бред, по моему. Можно было по дефолту такие включить.

Так вот. Опишу проблему более детально. По крайней мере попытаюсь.
У меня есть приложение. Оно довольно большое и в процессе работы может поедать довольно много памяти.
Я запускаю это приложение и оно работает вполне корректно. Ничто не падает. Запускаю так:

Всё отрабатывает без проблем!

Но конечному пользователю надо поставить один файл. Поэтому принято решение всё запихать в один jar, используя проект One-Jar (http://one-jar.sourceforge.net/). Всё это работает под JRE 1.6, не ниже. Поэтому решено было написать ещё загрузчик, который собирается под старую версию 1.2. Всё это находится в одном jar файле. Таким образом, запуская Jar, сначала мы передаём управление этому загрузчику. Он проверяет версию JRE. Если версия 1.6 и выше, то загружаем загрузчик One-Jar:

Этот загрузчик уже загружает проект и запускает его. В принципе, схема нормальная и работает. Но когда приложению требуется много памяти, то всё рушится. Вылетает OutOfMemory. Долго возился с причиной, версий много, но пока чёткой нет. Я так и не смог найти подробное описание работы HotSpot и вообще всех частей JVM. Однако проблему решил следующий способ запуска:

Т.е. я задал вручную инициализируемый размер кучи и максимальный размер кучи. После этого всё работает! Ничто не падает. OutOfMemory не возникает.

Я не до конца понимаю как работает JVM. Почему задание вручную размера кучи решает ситуацию? Какой размер по умолчанию у неё? Почему добавление системы BootStrap приводит к выпадению OutOfMemory? Ведь когда запускаешь без этих двух загрузчиков, то всё работает.

Так вот. Проблема всё таки решилась заданием -Xms150m -Xmx1000m. Но не могу же я пользователям писать чтобы они запускали апплет из коммандной строки с этими параметрами. Существует ли способ задания этих опций в файле Manifest или ещё каким-либо программным образом?

попробуй поработать профайлером и выявить кто жрет много памяти и если это твой код то правь его если нет то скорее всего придется пользоваться этими параметрами

программно не седлать такого, напиши батник который бы пользователи пускали а в нем уже все параметры проставленные 

в IDEA  вроде параметры такие проставляются в файле проперти но запускается чере файл idea.exe

Это сообщение отредактировал(а) _and - 16.4.2009, 11:38

Самое печальное, что у меня всё работает и не падает. Падает у тестеров. Хотя машины одни и теже вроде. Мне непонятно, по какой причине GC не освобождает память??? Запускал с флагом -verbose:GC, но что-то не увидел сообщений от GC. По идее, если он отрабатывать будет, то падать не должно. Хотя я не знаю. Может и правда памяти не хватает. Но кто ограничил её??? Почему без загрузчиков всё работает?
Свой код я и так уже переправлял! Уж не знаю что там не так!


bat-файл писать нельзя. Должен быть один jar. Чтобы пользователь кликнул по нему мышью и всё заработало. Да к тому же нужна кроссплатформенность.


Приложение должно быть кросспалтформенным. По крайней мере Windows и Linux.

А как нибудь при сборке может можно задать?

Это сообщение отредактировал(а) Bodro - 16.4.2009, 12:00

а если при клике на jar запускать какой-нить клас который после этого будет вызывать твой апплет с нужными параметрами, типа

Да вообще как то странно! К тому же всё в одном файле. Нужно указывать разные точки входа. Одна при клике по умолчанию, вторая точка это мой загрузчик. Да к тому же там и так уже два загрузчика: мой и One-Jar. И не уверен я что это будет нормально работать. Да к тому же это некрасиво. Это не пойдёт!

Смотри. Нашёл вот такие статьи: http://www.ibm.com/developerworks/ru/edu/j...t/section4.html, http://javahowto.blogspot.com/2006/06/fix-...emoryerror.html.
Так что можно указать размер кучи при компиляции. Сейчас попробую и скажу.

Можно в манифесте прописать какие дополнительные jar нужны для запуска RightSizer.jar
Тогда можно запускать командой java -jar RightSizer.jar
Для инталяции можно в RightSizerInstall.jar запаковать нужные jar и RightSizerInstall.class, который будет их распаковывать в указанную пользователем папку и добавлять ссылку на десктоп.

Да нельзя так делать! Я пишу коммерческое ПО. Если у пользователя нет прав на создание папок? Никаких инсталляторов, никаких распаковок и прочего. Должен быть один файл. Его надо запустить и чтобы всё работало.

В общем посмотрел я те статьи, проанализировал.
Могу предложить 4 способа задания фиксированного размера кучи. Возможно их больше.

1 способ:
указываем в ant-срипте для сборки:

memoryinitialsize="256m"
memorymaximumsize="256m"

2 способ:
указываем в виде дополнительных опций компилятору


3 способ:
указываем переменные окружения для ant


4 способ:
запускаем саму программу с нужными параметрами


Пробовал 1, 3, 4 способ. Работает только 4-й способ.
Посколько проект содержит два загрузчика, один из которых собирал не я, то я делал так:
Собирал свой загрузчик со следующими параметрами:

Собирал файлы программы так же. Выставлял переменные окружения. Не помогает! Помогает только запуск с нужными параметрами (способ 4). Возможно необходимо One-Jar пересобрать с такими опциями. Но не думаю что в этом дело. Хотя не знаю точно.

В чём может быть причина то?

Ха, читал я не внимательно! Написано же:

Эти те первые три способа что я указал вверху говорят именно javac что нужно собираться с такой кучей. Но на class файлах это никак не отображается! Получается мне подходит только четвёртый способ!
Потому что мне нужно во время выполнения много памяти. Компиляция проходит нормально.

Это сообщение отредактировал(а) Bodro - 16.4.2009, 15:07

я тебе не зря по-моему предложил сделать точку входа по умолчанию класс который будет вызывать нужный с определенными параметрами и чего в этом не красивого. Для твоего варианта это по-моему единственный выход IMHO/
просто покопай в эту сторону еще может интересного найдешь ну и соответственно с нами поделись как найдешь   

А имеешь ли ты право делать так?
Коммерческий jar может не разрешать так делать.
А если так сделать с jar с лицензией GNU, твой jar тоже должен иметь лицензию GNU, и ты должен открыть исходники.

/var/tmp должен быть открыт на запись, но там может не хватить места, чтобы развернуться.

Я пишу коммерческое ПО под нашей лицензией. С закрытыми исходниками. Условия лицензии One-Jar соблюдены.
А для пользователя нужно предоставить массу удобств. И программа работать будут не только в Linux, точнее она будет работать в основном в Windows и редко на других платформах. Создавать архив нельзя, потому что нельзя распаковываться. Если бы ты знал, какие бывают чудные пользователи!!! Небольшая трудность и они откажутся от ПО. Поэтому должно быть всё максимально удобно. Если поддерживается клик мышью по jar-файлу с автоматическим запуском, то так и должно быть. А если нет, то надо на сайте максимально понятно указать как запустить программу. Чтобы это было просто. Вот тебе всё понятно. А пользователю может быть не понятно. Он может вообще только что комп увидел и ему просто надо потыкать мышкой и получить результат. Так что должно быть всё просто.

А инсталлятор писать вообще нельзя! Под все платформы не напишешь. Да и сложно это, написать грамотный инсталлятор, который бы учёл все особенности.

Но всё равно большое спасибо!


Сейчас я этот вопрос обсуждаю с начальством. Но понимаешь, тут есть проблема. Я сделаю подобную систему, как ты описал. Но и этого объёма памяти может не хватить. Вот что написано в официальном документе от Sun по поводу управления памятью memorymanagement_whitepaper.pdf:

Так что если мне не хватит места, то необходимо вручную настраивать среду. Например так:

Сейчас вопрос остаётся открытый что делать с проблемой нехватки памяти.
Но я предерживаюсь мнения, что вообще надо всё оставить как есть и просто на сайте указать что в случае падения с ошибкой OutOfMemoryError необходимо запустить программу с параметрами -Xms, -Xmx, в которых указать необходимый размер кучи. Например:  -Xms150m -Xmx1000m.
Тогда кто понимает, настроит сам среду, а кто не понимает, просто с консоли введёт эти парметры и всё заработает. Но если и этого не хватит, то пусть или сам подбирает параметры или обратится в службу технической поддержки.
Мне кажется, это самый нормальный вариант.

Но вопрос решаю не я, а начальство.

хозяин барин как говорится   , тока о каком удобстве может идти речь 

Ну а вариантов нормальных то больше нет! Писать загрузчик практчески бесполезно! Ну укажу я там максимальных размер 1000 МБ. Ну а если и его не хватит? Мне что, указывать все 4ГБ в качестве максимального? Если только так.
На небольших наборах данным мне хватит и 64 МБ по умолчанию. А если выше, то пусть настраивают.

Варианты то какие?

ставь -Xms256m -Xmx512m этого должно быть вполне достаточно
для большинства пользерова те у которых не помогло пусть в тех поддержку идут
и все ж попробуй профайлером отловить место утечки полезнее будет

Это сообщение отредактировал(а) _and - 17.4.2009, 11:34

1 гига не хватит?  
Может оптимизацией пора в плотную заняться?  

Говорю же, у меня не воспроизводится, а воспроизводится на машине тестеров. Тестеры в другом городе. И у пользователей.
И профайлер запустить я не могу. Да к тому же у меня нет утечки памяти! А если есть, то не критичная.
Сам набор данных большой и хранить его надо в памяти. Иначе придётся сбрасывать на диск часть инфы, а это не желательно.
Да в этом случае придётся настраивать мусоросборник. Всё равно придётся лезть в консоль.


Специфика работы программы такая. Задачи бывают разные. Дело тут не в оптимизации.
Если я буду долго оптимизировать код, то всё равно это не факт, что памяти хватит. Он упадёт не на этом наборе данных, но на чуть большем.
Сама суть программы требует хранения большого объёма данных в памяти.

Вот это то не зря написали:

Тема закрыта.