View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000552 | LDMud 3.5 | Implementation | public | 2008-07-09 16:27 | 2011-02-13 21:38 |
| Reporter | zesstra | Assigned To | zesstra | ||
| Priority | low | Severity | minor | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Platform | i686 | OS | GNU/Linux | OS Version | 4.0 |
| Target Version | 3.5.0 | Fixed in Version | 3.5.0 | ||
| Summary | 0000552: Name clash between our ptmalloc and glibc ptmalloc | ||||
| Description | Gnomi 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. | ||||
| Tags | No tags attached. | ||||
|
|
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? |
|
|
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. |
|
|
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. |
|
|
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.) |
|
|
I no last minute objections, I will remove xptmalloc tomorrow. |
|
|
ptmalloc was removed in r2746. |
| 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 |
