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

·>Во как. Ты оказывается имел в виду не "хип GC" (чтобы это не значило), а область (area, generation) кучи.

Я имел ввиду именно другую кучу, в точности аналогичной нейтивной.

Я вижу, что у тебя затык на самом слове "куча", хотя это слово интуитивно понятно, ИМХО.
"Кучей" в менеджере памяти физически является набор страниц, взятый у операционки.
Дефолтный менеджер нейтивной кучи в виндах живет в Kernel32.dll, в линухах он живет в glibc.so.


·>И что ты хотел сказать-то этим?

Что большие объекты (т.е. память под них) обрабатываются джавовским GC по-другому, а именно — в точности как нейтивные.


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

Именно что RTFM, потом спорь.
По твоей ссылке нет противоречий моим словам.


V>>·>Бывает off-heap подход, но это не об объектах и их размерах, а по сути это просто in memory database. И off-heap как раз используется для хранения данных огромного кол-ва _мелких_ объектов.
V>>>>Чем куча GC отличается от обычной?
V>>·>Откуда я знаю что такое "обычная куча", этот термин ты придумал.
V>>Этому термину больше лет чем тебе.
·>Ну какая разница когда ты его придумал.

Придумываешь тут только ты от незнания.


V>>·>Скажем, в zing куча операционки может не использоваться, и там есть ядрённый модуль, который выделяет Java-кучу прямо в физической памяти.
V>>А бывает как-то иначе? ))
·>Бывает.

Не бывает. ))
У операционки с защищённой памятью всегда аллоцируется сначала адресное пространство, а потом коммитится, по мере надобности, её отображение на физическую память.


V>>Ясно, понятий ровно ноль.
V>>В обычной куче есть только две операции — выделение и освобождение памяти.
·>Можно ссылку на понятие "обычная куча"?

https://msdn.microsoft.com/en-us/library/windows/desktop/aa366599(v=vs.85).aspx



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

Для Джавы и дотнета они неразрывные.


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

Я ничего не путаю и в LOH никаких особенностей нет, — это обычная куча как куча, которая в современных менеджерах памяти представлена деревом на основе бинарного представления части адреса объекта. Просто конкретно MS дала этой куче название в своей реализации GC, чтобы как-то отделить, сугубо терминологически, её от основной кучи GC.

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

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.

В точности аналогично, кароч, и лично мне здесь не видится ничего удивительного.