[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::digital_unix

Title:DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:Welcome to the Digital UNIX Conference
Moderator:SMURF::DENHAM
Created:Thu Mar 16 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:10068
Total number of notes:35879

9576.0. "Malloc Algorithm best/first fit??" by BALTMD::GLOCK () Tue Apr 22 1997 12:01

    
    Can anyone help me address the following customer comment?  I am not a
    programmer and therefore do not know how malloc works.
    
    "The Alpha's malloc() is stupid.  It's first fit rather than best fit. 
    This means the second-to-last realloc() of my hashtab, which is 
    60MB long, gets reused by the next 10 byte allocation.  I'm searching 
    for a better malloc that's been tested on the Alpha, but I think it's 
    time to move to the next level."
    
    I guess the question is whether or not the malloc allocation algorithm
    can be changed from first-fit to best-fit by any means.
    
    Thanks for any assistance.
    
    Karl Glock
    DTN: 339-5244
T.RTitleUserPersonal
Name		DateLines
9576.1Being handled offlineQUARRY::nethCraig NethTue Apr 22 1997 12:082
Gee, I just answered this question via mail to Steve Leventer....
9576.2what's the answer?RHETT::MOORETue Apr 22 1997 12:321
    How about posting the answer anyway for those with inquiring minds?
9576.3Thanks...BALTMD::GLOCKTue Apr 22 1997 12:5110
    I guess that I also forgot to mention that this is DU 4.0-B and that
    the customer is running in a SUN Solaris environment in which his
    application performs the way he wants it to.
    
    This is the same customer that Steve is working with.  I will talk to
    Steve later today.
    
    Thanks for the quick reply
    
    Karl Glock
9576.4RE: .-2BALTMD::GLOCKTue Apr 22 1997 13:1724
    RE: .-2
    
    The malloc() included in all DIGITAL UNIX releases after V2.0 is actually
    quite "non-stupid" - it is NOT a simple 'first-fit' allocator.   The
    implementation uses a so-called 'cartesian' algorithm - it maintains
    lookaside lists of different block sizes.   The malloc() implementation in
    releases prior to V2.0 _was_ 'stupid'; is it possible this customer
    is either remembering that behavior or (horrors) still running a pre-V2.0
    version of the OS?   One other thing to check would be to see if the 
    application is using threads - the threads package in pre-V4.0 DIGITAL
    UNIX releases provided it's own allocator which wasn't as good as the
    non-threaded one provided on the base system.   In V4.0 of DIGITAL UNIX,
    the base system allocator was made thread-safe and the threads specific 
    allocator was retired.
    
    Now, of course, it is possible that there is still more tuning that could
    be done to our malloc() implementation, and that this customer has found
    an application where it performs less than optimally.   We would be _very_
    interested in working with the customer if that were the case, but would
    need more information (a testcase would be perfect) in order to pursue
    that.
    
    I am not aware of any alternative malloc() implementation for DIGITAL UNIX,
    but I didn't really look too hard.
9576.5QUARRY::nethCraig NethTue Apr 22 1997 14:0019
re: .4:

It would have been polite to ask me first or at least leave
the mail headers in before posting the mail _I_ sent to Steve as .4. 

I wrote the text posted in .4 before we had the additional information about 
the OS release version.

Regardless....

It sounds like the customer's application may have found some odd corner
of the malloc package.   Can you please either file a QAR, IPMT or get a copy 
of the application to us so that we can work on this issue - we would like 
to help - I know this is an important, high visibility customer...

Craig
9576.6BALTMD::GLOCKTue Apr 22 1997 15:3913
    
    I feel that I must apologize for not asking permission to post your
    information.  I thought that it contained a lot of useful information
    for various versions of DU.  It will not happen again.  
    
    I appreciate your rapid and detailed responses to this problem.
    
    I will talk to the customer to see what we can arrange with you.
    
    Thanks again for your assistance.
    
    Karl Glock
9576.7For the record:QUARRY::reevesJon Reeves, UNIX compiler groupWed Apr 23 1997 12:116
Both of the following are against company policy:

 . Posting private mail without permission
 . Stripping the original headers

See http://www-server.mso.dec.com/hrxxx/hr006-54.htm for specifics.