Возврат памяти в систему возможен только если есть достаточный пустой блок в конце кучи. Иначе это гроша выеденного не стоит.

Делал когда-то на Си  программу-буфер, которая должна была сглаживать пульсации между потоком UDP данных и потребителем без потерь, потому как потребитель мог временами тупить. Мне удавалось возвращать память, потребляя 100 кБ в норме и 100 МБ в пике. Но это особенность архитектуры программы, всего одна задача и все под нее заточено. У интерпретатора куда больше задач. Память сильно фрагментируется, освободить ее проблематично. Пустая трата времени.

Если вы хотите серьезно экономить память, куда более полезным может оказаться спуск крупных структур с адаптированным под задачу поиском в XS и выдачей SV/AV/HV только когда нужно.

++

возврат памяти в систему возможен если у нас есть достаточный пустой непррывный блок в любом месте кучи

Просто надо аллоцировать анонимную память на куче, а не двигать стек/дата сегмент.

Арена это набор аллоцированных кусков увеличивающихся с каждым разом. Первые освоьождать ничего не даст а последние заняты. Чтобы освободить один из кусков надо чтобы он полностью был свободен. В реальной жизни такое встретить сложно

достаточно, чтобы кусок был больше трешолда срабатывания для munmap()

Мы недавно делали тест. Там растёт 2 раза, когда share делаешь на sv. Потом ещё примерно в 2 раза, когда тред создаёшь и обращаешься к SV. Т.е. в общей сложности трудно сказать, что будет только в 2 раза.

Вообще в каждом треде свой интерпретатор запускается. Получается, что вообще всё-всё в своём "неймспейсе" работает.
В том числе и сокеты отделены.

Но pthread не обмануть и можно в дескриптор сокета по номеру из другого треда писать :)

Маллоки там прямо на мьютексах сделаны? Т.е. это даже не lock-free структуры данных?

Java умеет так дефрагментировать и ссылки перекидывать. Случаем не знаете, как там это устроено?
Просто не сказать, что java прям сильно медленнее c++ (слышал, что  в 1.5 раза  всего лишь).

Это не показатель хорошести джавы, это показатель плохости с++.
В джаве менеджед код и адреса там свои виртуальные. В результате обращение к каждому объекту через косвенную адресацию.

> В результате обращение к каждому объекту
> через косвенную адресацию.

А...! Это для знатного уменьшения быстродействия поди? 🤔😳😮

Ну тут или быстродействие, или возможность освобождать память

Перл писался еще до расцвета  реализации локфри. Нет ничего такого.

Во-первых, в jvm это как-то работает. Магии же не бывает, они тоже в оперативной памяти как-то перетаскивают куски памяти.
Во-вторых, тут как бы не только в освобождении дело, тут ещё и в выделении проблема тоже. Представьте ситуацию, что у вас память фрагментирована на маленькие куски. Причём 20 GB пяти свободно, но вы не можете в них выделить 10MB, потому что фрагметация памяти и невозможно найти непрерывный кусок такого размера.
Сама ОС умеет эту проблему решать, т.е. когда ей надо выделить память, а у неё всё фрагментировано, она как-то умеет перемещать (только то, что возможно переместить), чтобы выделить память.
А вот если ваш язык программирования забрал всю память (к примеру 40Gb, но реально используется только 20GB) и она расположена так, что сам язык программирования не может выделть каких-то 10MB, то это по-моему проблема.

В чём проблема это сделать сейчас?

ОС умеет работать с маппингом памяти на физическом уровне

Кому? Там 3.5 контрибутора.

Ну и треды никому не нужны, их наконец-то официально признали discouraged.

Кстати, интересно.
Есть ли какой-то паттерн (оправданный) использования тредов в перле?