всем привет.


недавно узнал что есть такая штука как  Java non-heap memory.  Кто то когда то сталкивался с использованием этой области памяти. Как туда что то ложить и вытягивать. может есть какието доки по этому поводу???

Non-heap? Полагаю, что речь идет о PermGen - области памяти, в которой хранится метадата о всех загруженных классах + кое что еще. 
Тут можно почитать о поколениях в памяти jvm (там речь о HotSpot) и о том, как это влияет на сборку мусора. 

не совсем... я слышал об этом из разговора нескольких програмистов ... и скажем так лишь краем уха... речь шла о том что в джаве можно использовать некую  non-heap  память. в целях кеширования своих обьектов. возможно это и она и есть... но мне нужна информация как туда что то писать и читать...

Например строки, которые кешируются с помощью метода intern(), идут в PermGen.

Возможно (не уверен) статические перменные тоже живут в пермгене - но я так понимаю, в спецификации это точно не обозначено, реализация зависит от вендора. Ведь проблема в том, что статические перменные можно переназначить, значит будут появлятся объекты, которые нужно собрать сборщиком. А это вряд ли хорошо для пермгена. 

мне было итересно все таки... если есть  non-heap  память... могу ли я с ней работать, ложить и четать от туда обьекты... естественно сам забочась о сборке мусора

А можно поинтересоваться, для какой цели это нужно? 


Как это?

 хм... точно еще не знаю... 

PermGen тоже подпадает под работу сборщика мусора если указать опции.

Наверное имелась ввиду память выделяемая средствами ОСи а не JVM.
Выделение и работа с такой памятью осуществляется написанием бинарного кода, платформозависимого кода и работой с ним через JNI/JNA
Применяется в высоконагруженных системах, и возможно реализован в серьезных фреймвораках кэширования.

http://www.terracotta.org/products/bigmemory ?

Аха, и сам не знал:
BigMemory achieves off-heap storage using Direct ByteBuffers, which is a feature introduced with NIO in Java 1.4 to allow zero copy buffers between Java applications and the operating system as it's not possible with memory belonging to Java heap because of unstable location
How does BigMemory hide objects from the Java garbage collector?

Direct buffers

NIO supports a type of ByteBuffer usually known as a direct buffer. Direct buffers can essentially be used like any other ByteBuffer (and are implemented as a ByteBuffer subclass), but have the property that their underlying memory is allocated outside the Java heap. More specifically, direct buffers have the following properties: 
 once allocated, their memory address is fixed for the lifetime of the buffer; 
 because their address is fixed, the kernel can safely access them directly and hence direct buffers can be used more efficiently in I/O operations; 
 in some cases, accessing them from Java can be more efficient (there's potentially less overhead in looking up the memory address and/or other housekeeping required before accessing a Java object)— see the example NIO buffer performance measurements made in Hotspot under Windows; 
 via the Java Native Interface, you can actually set the address arbitrarily if required (e.g. to access hardware at a particular address, or to perform the allocation yourself). 

In practice, in current versions of Hotspot, the memory is allocated via a malloc(), although this could vary in other VMs or in a future version of Hotspot.
Direct buffers

поидеи это оно... типа с этим  ByteBuffer  можно складывать байт масивы в не хипа

А как память чистить? Или все утекать будет? Вообще да, занятная штука.

Память собирается точно так же, как и обычная. В смысле, собирается объект типа ByteBuffer, и при этом в нем происходит сбор памяти. 

На самом деле там достаточно прозрачно всё сделано - память выделяется через Unsafe прямо в java-коде, создается обработчик, ее собирающий, и всё это кладется через PhantomReference в очередь. При сборке запускается обработчик и собирает память. Весь этот код доступен в исходниках по лицензии JRL, да и обычного src.zip хватит, чтобы разобраться, правда, без деталей.

Так что если грамотно всё организовать и не прикапывать жесткие ссылки - всё соберется. В Wicket 1.3.4 была такая утечка, потом поправили. 

Вообще держать данные вне хипа - плохая практика. Эта память собирается сильно сложнее и дольше, а необходимость вылезти за хип чаще всего говорит о том, что в приложении проблемы. За хипом память тоже не беспредельная. Предназначение прямого выделения - операции ввода-вывода. Выделенные в ОС буферы памяти могут сильно ускорить обмен с устройствами, ибо ОС будет с ними работать напрямую. А потом и нам можно напрямую, что тоже быстро.

Это сообщение отредактировал(а) Skipy - 7.11.2011, 12:21

Интересная статья на хабре на эту тему
Там ещё внизу поста есть ссылка на блог автора, тоже посоветую глянуть

  


Из "Интересная статья на хабре на эту тему":

Не подойдет для клиентского приложения. А для серверной системы в том, наверное, и состоит искусство разработчика, чтобы система получилась "слабо связанна" и "хорошо делилась логически". 


Это сообщение отредактировал(а) COVD - 8.11.2011, 03:32