Я использую 1.8.0_66 (пробовал как i586, так и x64. Пробовал так же более ранние), система - xubuntu 12.04 x64
То ли мне невезет и я постоянно попадаю на баги, то ли еще что.

Первая проблема заключается в том, что FileChannel.map "под капотом" работает на mmap и возвращает unmanaged-память, и там в глубине исходников (в srс.zip их нет, но если скачать с git или смотреть идеей то можно найти sun.nio.ch.FileChannelImpl.map) делается сначала маппинг, а потом делается new FileChannelImpl.Unmapper не обрамленное в try-catch. Если этот new кинет OOM, а выше это OOM будет поймано и обработано, то память останется замапленой навсегда - и будет утечка памяти. Эта проблема не очень актуальна. Когда я пытался воспроизвести ее - не получилось вызвать oom в нужном месте. Но это так, к слову. Просто вспомнилось про нее к случаю.

Вторая проблема жесче. jvm нормально не справляется со случаем, когда для FileChannel.map не хватает внешней памяти - и падает. Под "нормально не справляется" я подразумеваю, что она, похоже, то ли вообще не пытается запускать gc, толи запускает лишь предварительную подчистку, которой явно недостаточно. Во всяком случае, когда я в реальном проекте нарвался на этот баг, то обнаружил, что анмаппинг такой памяти делается при помощи ReferenceQueue<sun.misc.Cleaner> - и у меня создалось впечатление, что gc не дошел до чистки хипа, и стало быть, не подхватил Cleaner-ы, а они не освободили direct-память. Но все равно от такого падать не должно.

Следующий код падает, c cозданием hs_err_pid14523.log




Вывод:
jvmмы тут
Java HotSpot(TM) Server VM warning: Attempt to deallocate stack guard pages failed.
#
Java HotSpot(TM) Server VM warning: INFO: os::commit_memory(0xf669e000, 12288, 0) failed; error='Cannot allocate memory' (errno=12)
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 12288 bytes for committing reserved memory.
# An error report file with more information is saved as:
# /home/chabapok/NetBeansProjects/tests/JavaApplication3/hs_err_pid14523.log
Java Result: 1



Как я понимаю, если создался hs_err_pid - то это уже ненормально.

Насчет return c каментом (1). На машине с 4gb если этот return убрать - раз 10 выведет "мы тут" и потом все равно упадет. На машине с 16gb не падает, но повисает совсем, потом только kill -SIGKILL.

Проверил так же на винде. На винде такого бага с jvm похоже, что нету, но все равно gc не запускается и мы попадаем периодически туда, где блок "мы тут". Что вобщем-то тоже не очень хорошо.

При этом, в реальном проекте, в котором я на такое нарвался, у меня нету вообще SoftReference-ов. Просто мапятся какие-то фрагменты файла, а потом в эту же переменную мапятся другие фрагменты - я надеюсь, что старый обьект подчистится, но он иногда не подчищается.

Че делать? у оракла багтрекер же только для платных подписчиков?

Это искусственный пример. В реальном приложении файл когда-нибудь закроется, когда приложение остановят. Можно считать, что этот файл - кольцевой буфер. Существующие либы кольцевых буферов имеют шаг минимум 1сек, у меня тот же принцип, но шагом десятки мс + свои специфичные фичи.
В процессе работы делается map какого-то фрагмента, туда какое-то время что-то пишется и делается force, или из него что-то читается. И дальше этот MappedByteBuffer больше ненужен, (в идеале хотелось бы оставить его кэше). Смысла делать fc.close() - не вижу, т.к. пишется туда что-то постоянно. Реально такое кол-во буферов, чтобы вызвать баг, редкость, которой по идее быть не должно. Но все равно, факт неприятен. То есть получается, может быть такая форма oom, при которой все накроется.

В каких-то свободных либах, кстати видел такое: через рефлексию вытягивают Cleaner и дергают очистку руками. Я не хотел так делать, потому что хотелось хранить отмапленое в SoftMap...

На компе с 16gb, кстати, реальное приложение не падает - думаю, что оно успевает подчищаться штатными средствами. Это уже когда оно упало на слабой машине - я начал проводить исследовательскую работу и нарвался на такое.

Надо пойти посмотреть как в sqlite сделано...

fixxerМожно увидеть полный stacktrace с caused by от IOException?
ex.printStackTrace дает такое:

jvm
java.io.IOException: Map failed
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:939)
at prob2.JavaApplication3.main(JavaApplication3.java:30)
Caused by: java.lang.OutOfMemoryError: Map failed
at sun.nio.ch.FileChannelImpl.map0(Native Method)
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:936)
... 1 more
Java HotSpot(TM) Server VM warning: Attempt to deallocate stack guard pages failed.
Java HotSpot(TM) Server VM warning: INFO: os::commit_memory(0xf6713000, 12288, 0) failed; error='Невозможно выделить память' (errno=12)


BlazkowiczМожно проверить на Java 7.
1.7.0_45-x64 - то же самое.

fixxerВо-первых, где гарантия, что GC в вашем цикле будет вызван? Во-вторых, если будет вызван, то где гарантия, что ArrayList под SoftReference соберется, если хипа достаточно? А если не соберется, то хук на ReferenceQueue не отработает и direct memory не освободится.

Вобщем, да. ByteBuffer.allocateDirect тоже ничего не подчищает и выбрасывает OOME - но при этом, не крашит jvm, а FileChannel.map - крашит.

Blazkowiczhs_err_pid14523.log можно приаттачить?

Да, аттачу. Единственное что, полный лог - 5мб, причем, размер отмапленой области почти не влияет на размер hs_err_pid, и в нем очень много строк вида "7fa6315a4000-7fa6315a5000 rw-s 00302000 08:22 3932290 /tmp/1.tmp" - я их вырежу чтобы влезть в разрешенные форумом 150kb, вместо них там камент что они вырезаны.

Маленькое дополнение. Там в hs_err_pid я только что увидел, что там есть LD_LIBRARY_PATH, которое указывает на 1.8.0_60. его таким ставит Netbeans. Очевидно, это неправильно, но c 1.8.0_60 оно тоже крашится. И я только что переключил нетбинс на 1.8.0_66 - те же симптомы, так что дело не в этом.

BlazkowiczПамять засралась, Java не смогла создать поток и решила, что ну его. Всё штатно.

Мне это предположение нравится. Наверное, приблизительно все так и было. Может не поток, а какие-то внутрение нужды jvm. Выходит, не совсем и баг.

Итог такой. Попытался я заслать туда багрепорт, начать решил с наиболее "мелкого" бага. Но то ли из за моего паршивого английского, то ли еще чего-то, они сочли, что этот баг является разновидностью других багов, присвоили ему JDK-8144174 и сразу закрыли его как дубликат. (по ключевым словам баги, на которые они ссылались, не находились)

С тем, что это дубликат, не согласен (меня никто не спрашивал). Да, другие баги действительно похожи. В основном, люди просят, мол, сделайте нам unmap, который можно было б дернуть руками. Ответ - мы не знаем как его сделать, по таким-то причинам. Эти причины не являются актуальными в той проблеме, о которой я сообщил им.

Хз, делать еще 1 попытку или не доставать их. Если надумаю слать им еще раз, буду слать сразу с патчем.

Под виндой баг и у меня не проявлялся.

Я изучал исходники. В jvm есть ключик -XX:MaxDirectMemorySize, которым можно ограничить кол-во потребляемой внешней памяти. Но вот беда, он работает с ByteBuffer.allocateDirect, а то что мэпится из фалов, он не учитывает.

Так же, в FileChannelImpl внутрений класс Unmapper, содержит статические поля-счетчики потребляемой замапленой памяти. Если очень хотеть - можно вытащить себе эти счетчики, можно написать свою реализацию FileChannelImpl и т.д.

Но вцелом, пожалуй, что баг ненастолько критичный, чтобы всем этим заниматься. Я на него нарвался потому, что в моей программе был вечный цикл - то есть она некорректно работала и плодила много лишнего offheаp-мусора.

Вообще, FileChannelImpl написан достаточно похабно сейчас уже так не пишут. Видно, что это legacy-код, который делался еще в допотопные времена, а потом в него добавлялись наспех костыли.