This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients brian.curtin, loewis, neologix, pitrou, tim.golden
Date 2011-11-29.22:13:22
SpamBayes Score 1.10571e-08
Marked as misclassified No
Message-id <>
In-reply-to <1322600223.3292.23.camel@localhost.localdomain>
> I think it would be nice to know whether the patch has a chance of being
> useful before committing it. I did it as a thought experiment after the
> similar change was committed for Unix, but I'm not an expert in Windows
> internals. Perhaps HeapAlloc deals fine with fragmentation?

Unfortunately, the implementation of HeapAlloc isn't really documented.
If Reactos is right, it looks like this:

Blocks < 1024 bytes are allocated from per-size free lists.

Blocks < Heap->VirtualMemoryThreshold are allocated through the free
list for variable-sized blocks of the heap.

Other blocks are allocated through  ZwAllocateVirtualMemory, adding
sizeof(HEAP_VIRTUAL_ALLOC_ENTRY) in the beginning. I think this header
will cause malloc() to allocate one extra page in front of an arena.

>> As an alternative approach, Python could consider completely dropping
>> obmalloc on Windows, and using a Windows Low Fragementation Heap (LFH)
>> instead, with HEAP_NO_SERIALIZE (as the heap would be protected by the
>> GIL).
> I'm not sure that would serve the same purpose as obmalloc, which
> (AFAIU) is very fast at the expense of compacity.

I'd expect that LFH heaps are also very fast. The major difference I can
see is that blocks in the LFH heap still have an 8-byte header (possibly
more on a 64-bit system). So I wouldn't expect any speed savings, but
(possibly relevant) memory savings from obmalloc.
Date User Action Args
2011-11-29 22:13:23loewissetrecipients: + loewis, pitrou, tim.golden, brian.curtin, neologix
2011-11-29 22:13:23loewislinkissue13483 messages
2011-11-29 22:13:23loewiscreate