Здравствуйте, vdimas, Вы писали:

V>·>Во как. Ты оказывается имел в виду не "хип GC" (чтобы это не значило), а область (area, generation) кучи.
V>Я имел ввиду именно другую кучу, в точности аналогичной нейтивной.
В jvm есть только одна куча для объектов, называется Java Heap.

V>Я вижу, что у тебя затык на самом слове "куча", хотя это слово интуитивно понятно, ИМХО.
V>"Кучей" в менеджере памяти физически является набор страниц, взятый у операционки.
V>Дефолтный менеджер нейтивной кучи в виндах живет в Kernel32.dll, в линухах он живет в glibc.so.
Да пусть где угодно живёт. В нейтивной куче ява-объекты не живут, они живут в ява-куче (которая _может_ располагаться в нативной, это уже является деталями реализации конкретной VM).

V>·>И что ты хотел сказать-то этим?
V>Что большие объекты (т.е. память под них) обрабатываются джавовским GC по-другому, а именно — в точности как нейтивные.
От размера может зависеть в какой области кучи выделится объект — YG, TLAB, OG. Это всё части (поколения) одной и той же кучи. Понятия нативной кучи в JVM нет, это деталь реализации.

V>>>·>Нет никаких "обычных куч" в Яве. Есть только Java Heap. И все объекты живут именно там, независимо от размера.
V>>>Это не так.
V>·>Это так. RTFM: https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/garbage_collect.html
V>Именно что RTFM, потом спорь.
V>По твоей ссылке нет противоречий моим словам.
Там ровно одна куча для объектов. Есть другие блоки памяти, которые JVM может запросить у операционки (т.е. из нативной кучи) — код методов, стеки тредов, нативных хендлеров и т.п. Но не объектов ява.

V>>>·>Скажем, в zing куча операционки может не использоваться, и там есть ядрённый модуль, который выделяет Java-кучу прямо в физической памяти.
V>>>А бывает как-то иначе? ))
V>·>Бывает.
V>Не бывает. ))
V>У операционки с защищённой памятью всегда аллоцируется сначала адресное пространство, а потом коммитится, по мере надобности, её отображение на физическую память.
Ещё раз повторяю. В zing используется специальный ядреный модуль, который выделяет память прямо в _физической_ памяти, минуя виртуальную память операционки (чтобы исключить влияние оперционки на обращения к памяти, т.к. page faults создают latency spikes).

V>>>Ясно, понятий ровно ноль.
V>>>В обычной куче есть только две операции — выделение и освобождение памяти.
V>·>Можно ссылку на понятие "обычная куча"?
V>https://msdn.microsoft.com/en-us/library/windows/desktop/aa366599(v=vs.85).aspx
И как там можно расположить ява-объекты? А под linux, как я понимаю, надо wine ставить, чтобы был доступ к HeapCreate?

V>>>В куче GC дополнительно есть операции перемещения объектов, с целью уплотнения (дефрагментации).
V>·>GC и дефрагментация вещи ортогональные.
V>Для Джавы и дотнета они неразрывные.
Ими можно крутить независимо. Не знаю на счёт дотнета, но в яве дефрагметацию можно просто отключить. Так что таки разрывные.

V>·>Как эти области памяти называются? Ссылку плз.
V>·>Ты наверное путаешь с dotnet LOH, там да, есть какие-то особенности.
V>Я ничего не путаю и в LOH никаких особенностей нет, — это обычная куча как куча, которая в современных менеджерах памяти представлена деревом на основе бинарного представления части адреса объекта. Просто конкретно MS дала этой куче название в своей реализации GC, чтобы как-то отделить, сугубо терминологически, её от основной кучи GC.
Конечно нет, если не считать особенностью то, что в java нет LOH, по крайней мере в оракловой VM.

V>Upd
V>Про дотнет пишут то же, что и про джаву, кста:
V>

V>Any allocation greater than or equal to 85,000 bytes goes on the LOH. Copying large objects has a performance penalty, so the LOH is not compacted unlike the SOH. Another defining characteristic is that the LOH is only collected during a generation 2 collection.

Где такое про джаву пишут?