вопрос про освобождение памяти в питон 3.2

> Как гарантированно вернуть память в ОС?
Может вызвать gc.collect()?

> действительно ли del удаляет элемент словаря и возвращает память операционной системе?

Если в словаре была единственная ссылка на объект, то освобождает. А вот в ОС может и не вернуться, ибо фрагментация.

действительно ли del удаляет элемент словаря

Да

и возвращает память операционной системе?

Нет

Тривиальный пример:

m = {"aaa": SomeObject()}
smth = m["aaa"]
del m["aaa"]

Из массива удалится, но память не освободится. Объяснять почему?

> но память как жрал так и жрет.

Офигительно точная формулировка. Ты хочешь сказать, что размер резидентной памяти процесса не уменьшается, или что он растет?

>>Офигительно точная формулировка

да это сложно обьяснить, поэтому я хочу лишь узнать лишь про момент с удалением элемента.

я понял что ОС память обратно не получает.
Но у меня эта переменная забивается так, что сжирает все 8гб оперативки на сервере *facepalm*

при этом весь словарь убивать нельзя.

попробую вызывать gc.collect(), но если это не поможет - есть ли ещё способы?

ссылка на него одна единственная - tmp, поэтому попробую так:

tmp = list(d['element'])
del d['element']
gc.collect()

Ну значит скорее всего проблема с потоками может быть. Они у тебя может не завершаются вообще и висят плодятся и множатся

> попробую вызывать gc.collect(), но если это не поможет - есть ли ещё способы?

Попробуй втупую: self.storage['уникальный ключ'] = None

ссылка на него одна единственная

Если есть утечка, то ссылка не единственная.

петон не освобождает объекты в случае циклических ссылок. может, проблема в этом?

петон не освобождает объекты в случае циклических ссылок

А мужики то и не знали:

import weakref
import gc

class A:
    pass

storage = []
storage.append(A())
storage.append(A())

storage[0].ref = storage[1]
storage[1].ref = storage[0]

ref1 = weakref.ref(storage[0])
ref2 = weakref.ref(storage[1])

# Delete refs to objects
storage[:] = []
gc.collect()

assert ref1() is None
assert ref2() is None

блин. забыл добавить, что не убивает если есть циклические ссылки и в обоих объектах указан деструктор (__del__),

Если просто циклические - тогда убивает это да.

__del__

Это важный момент. Причем, в нём можно ручками ссылки и прибить.

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

Глупость сморозил, да. В этом случае отцу пролетариата помогут только слабые ссылки.

> действительно ли del удаляет элемент словаря

я это гарантирую.

man «программный хип»

А вот в ОС может и не вернуться

она абсолютно точно не вернётся и я ещё не видел чтобы где-то процесс рос в обратную сторону.

ибо фрагментация.

Не поэтому. Эта фича тупо нигде не реализована. Во всяком случае я ещё не видел реализации malloc которая бы делала brk/sbrk в меньшую сторону.

malloc не всегда делает brk. иногда mmap - в зависимости от размера блока. тогда munmap вернёт память.

Wikipedia, malloc:

For requests above the mmap threshold, the memory is always allocated using the mmap system call. The threshold is 256 KB (1 MB on ptmalloc2) by default, but can be changed by calling the mallopt function.

> Во всяком случае я ещё не видел реализации malloc которая бы делала brk/sbrk в меньшую сторону.

munmap делает, так что порой всё-таки память освобождается.

Круто, буду знать. Надо будет повторить опыты, три года назад вернуть память у меня не получалось.

см. коммент выше :)

Надо было malloc_trim вызывать :)

malloc_trim

Я знал что не зря сижу на лоре, нет-нет да и проскакивает интересная инфа. Спасибо большое, это может пригодится. Обидно то что в man malloc об этом ни слова.