Если XML - открыть для себя, что кроме DOM, есть еще и SAX.

Прочитать про устройство памяти в Java. Пока перлы "упадёт из-за нехватки какого-нить пермгена " думаю смотреть в сторону reference бессмысленно. Ну IMHO soft reference может чем то и хорош, но вот документация как он чиститься GC полный отстой. Если в проекте наплодите soft reference, боюсь падать оно не перестанет, а вот отладить место падение будет сложнее.

Выделить больше памяти, что бы файл точно в память помещался. Большие файлы парсить в отдельной Java машине, что бы если и упадет, было не так жалко ))). А, вообще, зависит от специфика задачи, проекта и доступного оборудования.

а чем тебе "size of" поможет? сравнить с потреблением своей программы/алгоритма

redwhite90...А вообще стало интересно где тогда парситься это всё будет?
Что значит парситься?

Банальный парсинг (например текстового файла), требует одного поля состояния парсера + 1-2 байта на текущей и пред. считанный символ. Зачем что-то большее? )))

redwhite90...приложение должно быть универсальным. Файлы могут взяться откуда угодно. А парситься они должны единообразно. И программа сама должна следить, чтобы онане взяла на себя слишком много.
Какие файлы и что значит "парситься" ?

Если нужна изоляция по памяти, то на мой взгляд, только запускать 2-ую (5,10-ую JVM) и выполнять парсинг там. В любом другом случае, способа гарантированно изолировать кусок кода от ядра нет. Или я такого способа не знаю.

Мало того, при работе в выделенной JVM, вполне возможно, может быть и значительное ускорение приложения. Т.к. ряд задач парсящих файлы, не будут гадить в общую кучу. Соответственно и куча может быть меньше (компактнее, больше в кеше процессора поместиться) и GC будет опять таки работать быстрее.

IMHO & AFAIK

redwhite90...Я смотрю сколько "ресурсов" я трачу сейчас, смотрю сколько "ресурсов" свободно, смотрю сколько "ресурсов" надо чтобы начать обрабатывать новый файл...
"трачу" это present contininue , а посмотреть это или past или даже past perfect ))). Сорри за мой английский.

Т.ч. в такой постановке вопроса - никак, в вопросе "падение падежей" ( C )

Зависит от задачи. Вашу задачу никто не знает. В "первом (втором, третьем и так далее) приближении" можно, но гарантий соответственно никаких.

1) Мы можем посмотреть, что сейчас 100 ресурсов свободно, а на деле, еще 100500 не почищенных GC свободного место. - сказали "облом", а на деле ресурсов полно.
2) Два потока: первый посмотреть, что 550 ресурсов свободно, запустился, второй посмотрел, 550 ресурсов свободно, запустился. Каждый потратил по 300 ресурсов и... - упали, а предположим, что еще и завалили ядро

И так далее

Или, работаем в предположении, что код написан _качественно_ и под JVM выделенно достаточно ресурсов. Или, что бы работать с гарантией, если файлы действительно большие и алгоритм _требует_ много памяти - запускать в отдельной JVM.

Но, для качественных алгоритмов, связи "размер памяти" -> "потребленная ОП память" быть не должно. IMHO & AFAIK.

Blazkowicz
Я бы для оценки:

1) брал бы размер еден спейс и умножал на кол-во сборок (минор) муссора - кол-во памяти засираемое алгоритмом в процессе работы
+
2) то, что после миннор GC осталось в памяти - кол-во памяти потребляемое на структуры

но мне кажется, что это не принесет счастья ТС и никак не решит задачу озаглавленную в Subj. IMHO & AFAIK

Leonid Kudryavtsev...связи "размер памяти" -> "потребленная ОП память" быть не должно. IMHO & AFAIK.

"размер файлы " -> "потребленная ОП память"...

И что делать, в этой обработке Out of memory ? Как она поможет.

Можно ключик java поставить и out of memory вообще никогда не будет )))

esy301sНу например....
Усложним вопрос. Два потока (два куска кода):
1. WebLogic отвечает на HTTP запрос.
2. Пользовательская обработка. Тоже в нескольких потоках.

Пользовательский процесс занял всю память. Когда работает поток WebLogic'а он пытается выделить буффер под HTTP запрос, запускается GC и падает с OutOfMemory.

1. Куда вставлять try ... catch..., если даже такую обработку вставили, как понять "кто виноват" и "что половинить"
2. Где гарантия, что для работы обработчика ошибок, осталось достаточно памяти ))) (можно попытаться настроить).
3. OutOfMemory не свидетельствует (как в C), что памяти нет. Оно лишь говорит, что GC подозревает, что памяти может не быть и дальше проводить garbage не разумно. Можно дать GC ключик и этой ошибки не будет. Будет по посинения мусор собирать и не выебы..ться. Т.ч. отсутствие ошибки, это не показатель, что все хорошо (настраивается).

Я не спорю, что сделать можно. Но надо ли.

Лично я бы, смотрел в сторону:
1. Нормальный алгоритм. Где требования к ресурсам не связаны (слабо связаны) с размером файла.
2. Если корреляция есть - ограничение на размер обрабатываемого файла
3. Если хочется полностью независимости по памяти - запускать дочернею JVM.

IMHO & AFAIK