ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : Slawa Olhovchenkov                   2:5030/500     16 Jan 2006  22:39:30
 To : All
 Subject : Вести с полей
 -------------------------------------------------------------------------------- 
 

 
 16 Jan 06, Slawa Olhovchenkov writes to All:
 
  SO> jasone      2006-01-13 18:38:56 UTC
 
  SO>   FreeBSD src repository
 
  SO>   Modified files:
  SO>     lib/libc/stdlib      malloc.3 malloc.c
  SO>   Log:
  SO>   Replace malloc(), calloc(), posix_memalign(), realloc(), and free() with
  SO>   a scalable concurrent allocator implementation.
 
 From: Jason Evans <jasone@freebsd.org>
 Subject: HEADSUP: malloc changeover
 
 libc's malloc(3) implementation has been replaced.  For now, all
 debugging, sanity, and statistics gathering options are enabled,
 which means that you can expect your programs to run slower and take
 up more memory.  We can shut these pessimizations off once it looks
 like the transition pains are mostly over.
 
 If you need better performance, undefine one or more of the following
 in src/lib/libc/stdlib/malloc.c:
 
         MALLOC_DEBUG
         MALLOC_STATS
         MALLOC_REDZONES
 
 All three slow programs down, and MALLOC_REDZONES also bloats memory
 usage.
 
 If you encounter runtime errors that you think are related to the
 malloc changes, please look at the man page and read about the
 various tuning flags, and use the relevant ones to try to narrow down
 the nature of the problem.  In particular, the 'A', 'J', 'Q', and 'Z'
 flags may be useful for this.
 
 The most likely types of application bugs that this malloc
 implementation will uncover are:
 
 * Bad alignment assumptions.  This malloc implementation only
 guarantees 16-byte alignment (for most architectures), even for very
 large allocations.  This is legal, but unusual.  Note that phkmalloc
 was very generous regarding object alignment.  If you discover a bug
 of this type in an application, see posix_memalign(3) when fixing the
 problem.
 
 * Buffer overruns.  Since this malloc implementation uses boundary
 tags, it is possible to corrupt internal malloc data structures by
 writing outside the bounds of an allocation.  Redzones will detect
 small overruns, but not large ones.
 
 I expect there to be numerous reports of problems as a result of this
 change.  Most of them will probably turn out to be application bugs,
 but bugs in malloc are possible (even probable) as well.  Let's all
 keep open minds as to the causes of problems while diagnosing them.
 
 Thanks,
 Jason
 
 ... Винда не пpиходит одна. (c) Microsoft Team
 --- GoldED+/BSD 1.1.5
  * Origin:  (2:5030/500)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

Тема:    Автор:    Дата:    Вести с полей   Slawa Olhovchenkov   16 Jan 2006 22:05:00   Вести с полей   Slawa Olhovchenkov   16 Jan 2006 22:39:30