Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #78682

Re: "High water" Memory fragmentation still a thing?

Return-Path <python-python-list@m.gmane.org>
X-Original-To python-list@python.org
Delivered-To python-list@mail.python.org
X-Spam-Status OK 0.001
X-Spam-Evidence '*H*': 1.00; '*S*': 0.00; '(even': 0.05; 'sufficient': 0.05; 'memory.': 0.07; 'strict': 0.07; 'tries': 0.07; 'invalidate': 0.09; 'pointers': 0.09; 'received:80.91': 0.09; 'received:80.91.229': 0.09; 'received:gmane.org': 0.09; 'received:list': 0.09; 'subject:skip:f 10': 0.09; 'subject:still': 0.09; 'python': 0.11; 'afterwards': 0.16; 'blocks': 0.16; 'garbage': 0.16; 'received:80.91.229.3': 0.16; 'received:dip0.t-ipconnect.de': 0.16; 'received:plane.gmane.org': 0.16; 'received:t-ipconnect.de': 0.16; 'size)': 0.16; 'extensions': 0.16; 'prevent': 0.16; 'split': 0.19; 'addition,': 0.20; 'later': 0.20; 'memory': 0.22; 'header:User-Agent:1': 0.23; '(such': 0.24; 'exhibit': 0.24; 'tend': 0.24; 'versions': 0.24; 'extension': 0.26; 'header:X-Complaints-To:1': 0.27; 'requests': 0.31; 'description,': 0.31; 'writes:': 0.31; 'another': 0.32; 'running': 0.33; 'announce': 0.33; 'becomes': 0.33; 'but': 0.35; 'charset:us-ascii': 0.36; 'possible': 0.36; 'subject:?': 0.36; 'operating': 0.37; 'to:addr:python-list': 0.38; 'recent': 0.39; 'does': 0.39; 'subject:" ': 0.39; 'to:addr:python.org': 0.39; 'enough': 0.39; 'system.': 0.39; 'received:org': 0.40; 'free': 0.61; 'new': 0.61; 'received:217': 0.63; 'become': 0.64; 'more': 0.64; 'burden': 0.68; 'limit': 0.70; 'heavy': 0.81; 'avoid.': 0.84; 'leak': 0.84; 'subject:High': 0.84; 'time)': 0.91; 'suffer': 0.93
X-Injected-Via-Gmane http://gmane.org/
To python-list@python.org
From dieter <dieter@handshake.de>
Subject Re: "High water" Memory fragmentation still a thing?
Date Sat, 04 Oct 2014 08:33:07 +0200
References <CANm61jc=pB7n+5kuea6bmYXTbo3hXLT8d4JZx3Yq-TBtgGrFOQ@mail.gmail.com>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
X-Gmane-NNTP-Posting-Host pd9e09ce3.dip0.t-ipconnect.de
User-Agent Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.22 (linux)
Cancel-Lock sha1:lFIZyUyl6Z8Z1lIlLslNruFLrfw=
X-BeenThere python-list@python.org
X-Mailman-Version 2.1.15
Precedence list
List-Id General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe <https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive <http://mail.python.org/pipermail/python-list/>
List-Post <mailto:python-list@python.org>
List-Help <mailto:python-list-request@python.org?subject=help>
List-Subscribe <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups comp.lang.python
Message-ID <mailman.14595.1412404402.18130.python-list@python.org> (permalink)
Lines 34
NNTP-Posting-Host 2001:888:2000:d::a6
X-Trace 1412404402 news.xs4all.nl 2885 [2001:888:2000:d::a6]:52536
X-Complaints-To abuse@xs4all.nl
Path csiph.com!usenet.pasdenom.info!bete-des-vosges.org!feed.ac-versailles.fr!nerim.net!novso.com!newsfeed.xs4all.nl!newsfeed2a.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Xref csiph.com comp.lang.python:78682

Show key headers only | View raw


Croepha <croepha@gmail.com> writes:
> Does python in general terms (apart from extensions or gc manipulation),
> exhibit a "high water" type leak of allocated memory in recent python
> versions (2.7+)?

Likely because it is very difficult to avoid. Would you need to
definitely prevent it is "memory compaction": not only is garbage
collected and freed but in addition, the used memory is also
relocated to form contigous blocks of used and free memory.

Without memory compaction, long running processes tend to suffer
from "memory fragmentation": while sufficient free memory is available,
it is available only in small blocks, not large enough for some memory
requests and those requests then call for more memory from the operating
system. When this memory is later released, it may become split up in
smaller blocks and when another large memory request arrives, new memory
may be requested from the operating system (even though the original
block would have been large enough).

Python tries hard to limit the effect of fragmentation (maintaining the
free blocks in bins of given size) but cannot eliminate it completely.


In order to support memory compaction, all C extensions must adhere
to a strict memory access protocol: they cannot freely use C pointers
to access the memory (as the compaction may invalidate those pointers
at any time) but must beforehand announce "I will now be using this pointer"
(such that the compaction does not move the memory) and afterwards
announce "I am no longer using this pointer" (such that memory
compaction becomes again possible for this memory).

As you see from the description, memory compaction presents a heavy burden
for all extension writers.

Back to comp.lang.python | Previous | Next — Next in thread | Find similar | Unroll thread


Thread

Re: "High water" Memory fragmentation still a thing? dieter <dieter@handshake.de> - 2014-10-04 08:33 +0200
  Re: "High water" Memory fragmentation still a thing? Marko Rauhamaa <marko@pacujo.net> - 2014-10-04 11:27 +0300
  Re: "High water" Memory fragmentation still a thing? bryanjugglercryptographer@yahoo.com - 2014-10-06 10:10 -0700

csiph-web