Есть код вида:



после обработки нескольких тысяч файлов возникает исключение



java version "1.6.0_33"
Java(TM) SE Runtime Environment (build 1.6.0_33-b03)
Java HotSpot(TM) Client VM (build 20.8-b03, mixed mode, sharing)

Windows 7 32 бит

Размер памяти у процесса в диспетчере задач не превышает 40Мб (запущен с опцией -Xmx1500m), в jvisualvm размер Heap не превосходит 20Мб.

Как диагностировать ошибку?

BlazkowiczFileChannel-ы не пробовали закрывать?Переписал так:



Та же ошибка на том же файле.

В JVM можно как-нибудь посмотреть счетчик этих file mapping objects?

schwaУ вас файлы большие небось.Большая часть из них не превышает 1Мб, но есть файлы до 150Мб. Файлов всего, наверное, тысяч 20. Общий размер получаемого файла должен быть где-то 4Гб.

BlazkowiczТак с одним и тем же файлом проблемы?За то время как я начал отслеживать эту ошибку (со вчерашнего вечера) - она постоянно возникает на одном и том же файле размером 84Мб. Перед ним успешно добавляются более 17 тысяч других файлов.

Excessive native memory growth with NIO due to finalization delayThe java.nio package added DirectByteBuffer and MappedByteBuffer classes that allocate native memory on the native C heap and via a platform specific memory mapping function (mmap()).
... the native C heap grows to nearly 2G before a minor GC event occurs.Проблема, я так понимаю, не в "native C heap" - память занимаемая процессом не превышает 40Мб (в нее же включается native куча?). Насчет "via a platform specific memory mapping function" - не знаю как посмотреть эту память, но общие показатели памяти системы вполне нормальные. Например, "Доступная память" во время работы не опускается меньше 2Гб.

Basil A. SidorovЯ правильно понимаю, что суммарный размер этих семнадцати тысяч файлов - около полутора гигабайт?Не замерял, но файл после ошибки был размером 2,2Гб.

Basil A. SidorovНасколько "не превышает"? Даже десять тысяч по мегабайту - уже десять гигабайт. Никак не четыре.Много файлов размером меньше килобайта, много - 2-3 килобайта.

Basil A. Sidorovне надо пытаться отображать в память файл размером около четырёх гигабайт целиком JVM дается команда скопировать данные. Команда целиком отобразить файл в память ей не дается. Во втором примере вообще выходной файл в каждом цикле затирается.

Basil A. SidorovНет такой команды. Есть "отобразить в память". Цель такого отображения - за рамками "разумения" JVM.
Basil A. Sidorovкопируйте "по рабоче-крестьянски" - через чтение-запись. Для буфера размером один-два мегабайта от способа копирования будет зависеть только загрузка проца.
JDK apidocs transferToThis method is potentially much more efficient than a simple loop that reads from this channel and writes to the target channel. Many operating systems can transfer bytes directly from the filesystem cache to the target channel without actually copying them.

schwaФайлы размером больше 2 гигабайт нельзя так обрабатывать.Где такое написано? И зачем тогда аргументы position и count типа long?

schwaТ.к. offset и limit там внутрях эти буферов знаковые int-ы и ими больше 2 GB никак не адресовать.Ну смысл для копирования 1Гб файла выделять в памяти 1Гб буфер? Вы думаете, что sun'овцы только до этого могли додуматься, когда создавали java.nio?

Basil A. SidorovdgxJVM дается команда скопировать данные.Нет такой команды. Есть "отобразить в память". Цель такого отображения - за рамками "разумения" JVM.Команда целиком отобразить файл в память ей не дается.Я не вижу кода, который задаёт размер отображаемого окна и переотображает его на разные части файла.JVM дается команда скопировать данные из одного файла в другой. Команды использовать отображение в память ей не дается. Если на ОС, на которой исполняется этот код доступно отображение в память, JVM может использовать эту возможность по своему усмотрению. Нигде в коде не указывается, чтобы она целиком файл отображала в память.

schwaФайлы размером больше 2 гигабайт нельзя так обрабатывать.
Basil A. SidorovНигде в коде не указывается, чтобы она целиком файл отображала в память.И? Где указано, что по умолчанию не могут и не будут использоваться все доступные ресурсы и даже сверх того?Вобщем да. HotSpot JVM в случае transferTo(), похоже, пытается полностью отображать (File Mapping) файл на память. Попытка скопировать большие файлы (уже даже 300Мб) таким способом приводит той же или похожим ошибкам. И, вроде бы, отображения от предыдущих вызовов еще какое-то время существуют, занимая адресное пространство и память.

Basil A. SidorovJVM дается команда скопировать данные из одного файла в другой.А вы внимательно прочитайте описание transferTo/transferFrom, которые передают данные из одного буфера в другой.Вот не нашел я такого. Может использоваться один буфер - непосредственно кэш файловой системы ОС.
JDK FileChannelBytes can be transferred from a file to some other channel, and vice versa, in a way that can be optimized by many operating systems into a very fast transfer directly to or from the filesystem cache.
"Java NIO" by Ron HitchensThe transferTo() and transferFrom() methods allow you to cross-connect one channel to another, eliminating the need to pass data through an intermediate buffer. ... Channel-to-channel transfers can potentially be extremely fast, especially where the underlying operating system provides native support. Some operating systems can perform direct transfers without ever passing the data through user space.

Basil A. SidorovТ.е. описание интерфейса функций transferFrom и transferTo в штатной документации для вас - не аргумент???Из этого описания не следует, что JVM должна выделять в памяти какие-то дополнительные буферы.

Basil A. SidorovВас, вероятно, привлекает выделенное жирным шрифтом?Я привел цитаты, в которых говорится, что существуют реализации JVM (использующие соответствующие возможности ОС), в которых данные фактически хранятся только в кэше файловой системы и не копируются в другие области памяти. Ron Hitchens пишет, что некоторые ОС способны передавать данных так, что эти данные вообще не попадают в пользовательское пространство (т.е. в процесс JVM).

В Windows диспетчер кэша отслеживает, какие части и каких файлов находятся в кэше. Выделеняя явно буфер памяти в куче процесса и осуществляя копирование данных кодом (не страничным отображением), Вы:
1. лишаете диспетчер кэша возможности отследить какие данные в памяти соответствуют данным на диске, существенно снижая его возможности оптимизировать работу с устройством внешней памяти,
2. уменьшаете память, доступную под кэш ОС.
Все это приводит к увеличению количества:Basil A. Sidorovсамое медленное "прочитать с диска, записать на диск и спозиционировать головки".

И скажите, Вы этой дискуссией чего хотите добиться?