home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / sun / misc / 6087 < prev    next >
Encoding:
Internet Message Format  |  1992-12-31  |  2.3 KB
  1. Xref: sparky comp.sys.sun.misc:6087 comp.unix.solaris:447 comp.unix.misc:4785
  2. Path: sparky!uunet!auspex-gw!guy
  3. From: guy@Auspex.COM (Guy Harris)
  4. Newsgroups: comp.sys.sun.misc,comp.unix.solaris,comp.unix.misc
  5. Subject: Re: mallopt() a no-op in SunOS 4.1.x?
  6. Message-ID: <16184@auspex-gw.auspex.com>
  7. Date: 31 Dec 92 21:42:28 GMT
  8. References: <1hqdriINNh67@armory.centerline.com>
  9. Sender: news@auspex-gw.auspex.com
  10. Followup-To: comp.unix.solaris
  11. Organization: Auspex Systems, Santa Clara
  12. Lines: 37
  13. Nntp-Posting-Host: auspex.auspex.com
  14.  
  15. >Can anyone either verify or refute the observation that mallopt, although 
  16. >it's present in the C library, seems to be a no-op in SunOS 4.1.x?
  17.  
  18. Yup, I can verify it.
  19.  
  20. The *only* place in the 4.1[.x] "malloc()" where it looks at, rather
  21. than just updating, any of the items in its internal "mallinfo"
  22. structure is a place where it updates "smblks"; the comment for that
  23. code reads "kludge to pass the SVVS", and all it does is, based on
  24. whether the number of bytes being returned by "malloc()" is bigger than
  25. "mxfast" or not, increment or not increment "smblks".
  26.  
  27. The problem is that AT&T embedded the implementation quirks of their
  28. "-lmalloc" version of "malloc()" in the SVID; SunOS has traditionally
  29. used its own "malloc()" implementation - to quote a comment at the
  30. beginning of it, it's
  31.  
  32.     based on a method described in C.J. Stephenson, "Fast Fits"
  33.  
  34. (i.e., it's neither the traditional V7 "malloc()", the Caltech
  35. "malloc()" used by BSD, nor the "-lmalloc" implementation in SV) - so
  36. those implementation quirks didn't apply.
  37.  
  38. In order to obey the "letter of the law", the "mallopt" glop was stuck
  39. in; it doesn't affect the behavior of the implementation, it just
  40. provides some statistics that keep the SVVS happy.
  41.  
  42. >Compiling and running the attached program on a variety of systems -- an
  43. >HP/700 running HP/UX 8, a sparc running SunOS 4.1.1, and a sparc running 
  44. >Solaris 2.1 -- suggests that mallopt actually has some effect in HP/UX 
  45. >and in Solaris, but no effect at all in SunOS 4.
  46.  
  47. HP-UX probably uses the standard SVR2 or SVR3 "-lmalloc" implementation,
  48. and SunOS 5.x may use the standard SVR4 implementation rather than the
  49. implementation used by previous SunOS releases (I think the SVR4
  50. implementation may be different from the one used by previous SV
  51. systems, as well).
  52.