View Issue Details

IDProjectCategoryView StatusLast Update
0000552LDMud 3.5Implementationpublic2011-02-13 21:38
Reporterzesstra Assigned Tozesstra  
PrioritylowSeverityminorReproducibilityN/A
Status resolvedResolutionfixed 
Platformi686OSGNU/LinuxOS Version4.0
Target Version3.5.0Fixed in Version3.5.0 
Summary0000552: Name clash between our ptmalloc and glibc ptmalloc
DescriptionGnomi investigated today a curious crash and found the root cause: the driver as well as the glibc implement ptmalloc (it is nowadays the default memory allocator of glibc). Unfortunately, the names of variables and functions are the same in both. This can be a problem, if it is not possible to replace the system malloc by our own (->SBRK_OK). See also 0000550.
We should discuss, how to clean up our ptmalloc stuff:
a) rename variables and functions of our built-in ptmalloc
b) update built-in ptmalloc and rename variables and functions
c) detect if the host's libc is an up-to-date glibc and fallback to use the ptmalloc of glibc, which is essentially a fallback to the sysmalloc allocator in the driver, I guess?
d) drop ptmalloc altogether?
e) leave it as it is
f) ?

With the patch from 0000550, the problem should have no immediate effect on users because driver.h enforces SBRK_OK if ptmalloc is used as allocator, because the driver won't work otherwise.
TagsNo tags attached.

Activities

zortek

2008-07-09 22:42

reporter   ~0000711

My choice of ptmalloc was based upon the premise that it is threadsafe (traditionally scaling well in performance) and supports garbage collection. Additionally, while it has not yet proven itself, I was also trying to consider heap usage to head off potential scaling issues (but to be honest, I'm not certain that the "anonymous page" strategy is a valid argument anymore).

With the assurance from our efforts re> 0000550 and Gnomi's investigation, I'd support deprecating ptmalloc and let it die on the vine.

However, my advocacy of dropping ptmalloc might myopically disregard a legacy community.

Is there some additional reasoning for either maintaining or rev'ing the built-in? Where is the greatest return for the investment of time required? Can action on this be deferred to 3.5?

fufu

2008-07-10 06:50

manager   ~0000716

Ok, I had a chat with Gawain (the original contributor of the pthreads comm code and the ptmalloc code) about this.

To summarize:
- xptmalloc is a threadsafe allocator with (single threaded) GC support. The latter point is the main difference between ptmalloc and sysmalloc, if the system's malloc is threadsafe.
- currently, the driver only allocates and frees memory from a single thread, so thread safety of the allocator isn't much of a concern.
- in fact, the comm.c code uses the system's malloc for buffers nowadays.
- in the long run, we should detangle the GC code from the allocator code.

So I think we can safely deprecate the ptmalloc stuff, and probably drop it for 3.5.

zesstra

2009-03-04 16:06

administrator   ~0000975

I suggest to keep it 'as-is' for 3.3 and decide at the beginning of 3.5, if we want to keep or drop it. BTW: To decouple the GC from the allocator code would be nice.
Transferring to 3.5 for now.

zesstra

2009-09-12 04:33

administrator   ~0001263

Now that we are working on 3.5: do we want to drop xptmalloc? I vote for yes.

(For decoupling the GC from the allocator we should create a new issue.)

zesstra

2009-09-18 05:22

administrator   ~0001278

I no last minute objections, I will remove xptmalloc tomorrow.

zesstra

2009-09-20 03:47

administrator   ~0001281

ptmalloc was removed in r2746.

Issue History

Date Modified Username Field Change
2008-07-09 16:27 zesstra New Issue
2008-07-09 22:42 zortek Note Added: 0000711
2008-07-10 06:50 fufu Note Added: 0000716
2009-03-04 16:06 zesstra Note Added: 0000975
2009-03-04 16:06 zesstra Status new => confirmed
2009-03-04 16:06 zesstra Project LDMud => LDMud 3.5
2009-09-12 04:33 zesstra Note Added: 0001263
2009-09-18 05:22 zesstra Note Added: 0001278
2009-09-18 05:22 zesstra Assigned To => zesstra
2009-09-18 05:22 zesstra Status confirmed => assigned
2009-09-20 03:47 zesstra Note Added: 0001281
2009-09-20 03:47 zesstra Status assigned => resolved
2009-09-20 03:47 zesstra Fixed in Version => 3.5.0
2009-09-20 03:47 zesstra Resolution open => fixed
2011-02-13 21:38 zesstra Target Version => 3.5.0