Hi Mark,
On Aug 25 00:29, Mark Geisert wrote:
> Hi Corinna,
> Well, this patch turned out to be half-baked. Locking is working correctly
> because USE_LOCKS was set to 1 for malloc.cc's compilation. The torture
> test I run validated that. OTOH as you said, MSPACES was set 1 for
> malloc.cc but
Hi Corinna,
Well, this patch turned out to be half-baked. Locking is working correctly
because USE_LOCKS was set to 1 for malloc.cc's compilation. The torture test I
run validated that. OTOH as you said, MSPACES was set 1 for malloc.cc but 0 for
malloc_wrapper.cc. So this patch yields a mal
Hi Mark,
On Aug 23 21:59, Mark Geisert wrote:
> 1. Replace global malloc lock with finer-grained internal locks.
> 2. Enable MSPACES, i.e. thread-specific memory pools.
>
> Porting and testing of several dlmalloc-related malloc implementations
> (ptmalloc, ptmalloc2, ptmalloc3, nedalloc) shows th
1. Replace global malloc lock with finer-grained internal locks.
2. Enable MSPACES, i.e. thread-specific memory pools.
Porting and testing of several dlmalloc-related malloc implementations
(ptmalloc, ptmalloc2, ptmalloc3, nedalloc) shows that they are no faster
than the current dlmalloc used by C
