| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
Notes:
svn path=/head/; revision=28830
|
| |
|
|
| |
Notes:
svn path=/head/; revision=27698
|
| |
|
|
|
|
|
|
| |
PR: 4002
Pointed out by: bde
Notes:
svn path=/head/; revision=27179
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dmitrij Tejblum <dima@tejblum.dnttm.rssi.ru>
Various cleanup from Keith Bostic
Reinstate calloc() as a separate funtion, in its own source/object file.
leave the manpage integrated with malloc.3 and friends. Too many things
were broken in this respect.
PR: 4002
Reviewed by: phk
Submitted by: Dmitrij Tejblum <dima@tejblum.dnttm.rssi.ru>
Submitted by: Keith Bostic <bostic@bostic.com>
Notes:
svn path=/head/; revision=27152
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Various portability and stylistic cleanups.
Kill MALLOC_STATS & the 'D' option.
Fix the 'V' option.
Major overhaul of the man-page.
You milage should not vary.
Reviewed by: Keith Bostic <bostic@bostic.com>
Submitted by: Keith Bostic <bostic@bostic.com>
Notes:
svn path=/head/; revision=26816
|
| |
|
|
|
|
|
| |
Prompted by: X11 & XFree86
Notes:
svn path=/head/; revision=26579
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Malloc cannot use pthread_mutex_init() to initialize a mutex because
the mutex initialization process does a malloc!
libc_r internals skip the malloc and assign an initializer to a static
structure and point the opaque type (pthread_mutex_t in this case) to
that structure. This is done on the assumption that the mutex will never
be destroyed. This style of initialization is only valid inside libc_r
because the structure that is assigned is opaque to the user.
This fix allows a simple program to get to main() again. 8-)
Notes:
svn path=/head/; revision=26444
|
| |
|
|
|
|
|
|
|
|
| |
Untested support for Solaris from John-Mark Gurney
Reviewed by: phk
Submitted by: (partially) John-Mark Gurney <gurney_j@resnet.uoregon.edu>
Notes:
svn path=/head/; revision=26284
|
| |
|
|
|
|
|
|
| |
Tested by: Joel Maslak <j@pobox.com>
Closes: PR kern/2964
Notes:
svn path=/head/; revision=23981
|
| |
|
|
| |
Notes:
svn path=/head/; revision=22993
|
| |
|
|
|
|
|
|
|
|
|
| |
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
Notes:
svn path=/head/; revision=21673
|
| |
|
|
|
|
|
| |
Submitted by: John Birrell <jb@cimlogic.com.au>
Notes:
svn path=/head/; revision=21000
|
| |
|
|
|
|
|
|
|
|
| |
with a NULL pointer (archie)
Explain that minsize is also the smallest alignment.
Submitted by: Archie Cobbs <archie@whistle.com>
Notes:
svn path=/head/; revision=19257
|
| |
|
|
|
|
|
|
|
| |
Improve chances of troublefree 64bit operation. [imp]
Noticed by: Warner Losh <imp@village.org>
Notes:
svn path=/head/; revision=19191
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add progname to warning/error message layout. (joerg)
Remove inline assembler, no speed impact, not need for the obfuscation (bde)
Remove on the fly calculation of parameters, no longer critical.
Make D & U flags valid even if we don't support them.
Don't call imalloc until we're done initializing.
Zap contents on free() if we have "Junk" set. [*]
Various nitpicking.
[*] As a sideeffect of this change, if you are worried about
sensitive data lingering in memory, you can use the 'Junk' option
now to make sure phkmalloc zaps memory when it is returned. add
char * malloc_options = "J";
to your source. Obviously there is a performance impact.
Notes:
svn path=/head/; revision=19057
|
| |
|
|
|
|
|
| |
Reviewed by: phk
Notes:
svn path=/head/; revision=18495
|
| |
|
|
|
|
|
| |
Submitted by: jdp
Notes:
svn path=/head/; revision=18493
|
| |
|
|
|
|
|
|
|
|
|
| |
Various neat features added. More documentation in the manpage.
If your machine has very little RAM, I guess that would be < 16M
these days :-(, you may want to try this:
ln -fs 'H<' /etc/malloc.conf
check the manpage.
Notes:
svn path=/head/; revision=18479
|
| |
|
|
|
|
|
|
|
|
| |
as done after a quasi-recursive call to free() had modified what we
thought we knew about the last chunk of pages.
This bug manifested itself when I did a "make obj" from src/usr.sbin/lpr,
then make would coredump in the lpd directory.
Notes:
svn path=/head/; revision=18333
|
| |
|
|
| |
Notes:
svn path=/head/; revision=16941
|
| |
|
|
|
|
|
|
|
| |
Submitted by: John Birrel(L?)
changes for threadsafe operations
Notes:
svn path=/head/; revision=13545
|
| |
|
|
|
|
|
| |
Found by: Lars Fredriksen <fredriks@mcs.com>
Notes:
svn path=/head/; revision=13268
|
| |
|
|
|
|
|
|
| |
Reviewed by: phk
Submitted by: Kaleb Keithly <kaleb@x.org>
Notes:
svn path=/head/; revision=12918
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
via mmap() up around the shared library area. Previously the directory
was allocated from space from it's own memory pool. Because of the way it
was being extended on processes with large malloced data segments (ie: inn)
once the page directory was extended for some reason, it was not possible
to lower the heap size any more to return pages to the OS.
(If my understanding is correct, page directory expansion occurs at 4MB,
12MB, 20MB, 28MB, etc.) I was seeing INN allocate a large amount of short
term memory, pushing it over the 28MB mark, and once it's transient demands
hit 28MB, it never freed it's pages and swap space again.)
I've been running this in my libc for about a month...
Also, seperate MALLOC_STATS from EXTRA_SANITY.. I found it useful to call
malloc_dump() from within INN from a ctlinnd command to see where the hell
all the memory was going.. :-) I've left MALLOC_STATS enabled, as it has
no run-time or data storage cost.
Reviewed by: phk
Notes:
svn path=/head/; revision=12776
|
| |
|
|
| |
Notes:
svn path=/head/; revision=11665
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"zero' and 'junk' options to help find and diagnose malloc abuse.
EXTRA_SANITY defaults "junk" to on.
Don't dump the internal state, unless EXTRA_SANITY.
General code cleanup.
Error messages cleaned up a bit, more checking earlier.
EXTRA_SANITY is default at this time (just in case).
Performance (without EXTRA_SANITY) is better, beats gnumalloc in
both time & space most of the time:
# In-memory test.
./malloc 50000000 2000 8192
159.2u 1.5s 2:41.85 99.3% 5+7742k 0+0io 0pf+0w
./gnumalloc 50000000 2000 8192
272.6u 0.4s 4:35.01 99.3% 5+8533k 0+0io 0pf+0w
# Swap-space test.
./malloc 500000 14000 8192
6.5u 4.1s 4:08.87 4.3% 5+49209k 0+0io 9772pf+0w
./gnumalloc 500000 14000 8192
16.2u 14.5s 15:36.14 3.2% 5+54100k 0+0io 47651pf+0w
# Small items test.
./malloc 20000000 20000 2048
67.0u 0.3s 1:07.83 99.2% 5+18199k 0+0io 4pf+0w
./gnumalloc 20000000 20000 2048
66.2u 0.3s 1:07.03 99.3% 5+18107k 0+0io 0pf+0w
SANITY is not an option anymore. (!!)
Notes:
svn path=/head/; revision=11338
|
| |
|
|
|
|
|
| |
Submitted by: Mike Pritchard <mpp@mpp.minn.net>
Notes:
svn path=/head/; revision=10952
|
| |
|
|
|
|
|
|
|
|
| |
Performance is comparable to gnumalloc if you have sufficient RAM, and
it screams around it if you don't.
Compiled with "EXTRA_SANITY" until further notice.
see malloc.3 for more details.
Notes:
svn path=/head/; revision=10818
|
| |
|
|
| |
Notes:
svn path=/head/; revision=8870
|
|
|
Notes:
svn path=/cvs2svn/branches/unlabeled-1.1.1/; revision=1573
|