gary@cirl.UUCP (Gary Girzon) (09/03/85)
I would appreciate some help on the following problem. When using malloc() in C ( runing 4.2 bsd ), I cannot allocate more than roughly 4 megabytes. This seems to be limited by our core size. I would like to know whether this limit can be extended to handle virtual memory on the VAX. Also, any information on how the C compiler deals with virtual memory (if at all) would be appreciated. Gary Girzon UUCP: ihnp4!think!cirl!gary
anton@ucbvax.ARPA (Jeff Anton) (09/05/85)
In article <203@cirl.UUCP> gary@cirl.UUCP (Gary Girzon) writes: >I would appreciate some help on the following problem. When using >malloc() in C ( runing 4.2 bsd ), I cannot allocate more than roughly >4 megabytes. This seems to be limited by our core size. I would >like to know whether this limit can be extended to handle virtual >memory on the VAX. Also, any information on how the C compiler deals with >virtual memory (if at all) would be appreciated. The C compiler does not bother with VMem knowledge except for its own use. You are probably encountering a limit imposed by malloc. I'd suggest you try useing sbrk(2). I recently needed a 6 Mbytes for raster plotting and malloc complained but sbrk worked fine. I don't suggest running jobs that exceed system core size, but sometimes we don't have any way around the matter. You might also try out the 'limit' command in csh. Check out sbrk(2), setrusage(2), and the 'obsolete' vadvise(2). (vadvise is hidden in 4.2 for use by lisp, and some CAD tools, and maybe apl; it might be named Ovadvise) -- C knows no bounds. Jeff Anton U.C.Berkeley Ingres Group ucbvax!anton anton@BERKELEY.EDU
chris@umcp-cs.UUCP (Chris Torek) (09/06/85)
The 4.2 malloc rounds each request up to the nearest power of two (sounds space inefficient [and is], but very time efficient; see Korn's paper in Proceedings Winter '85 Usenix). Since as distributed 4.2 has a per-process VM limit of 6M, you cannot allocate more than 4M with malloc. (Of course if you raise the VM limits you can get as much space as you like, provided you have lots of paging space.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
hosking@convexs.UUCP (09/17/85)
> Since as distributed 4.2 has a per-process VM limit of 6M, you cannot > allocate more than 4M with malloc. (Of course if you raise the VM > nlimits you can get as much space as you like, provided you have lots > of paging space.) It turns out to be pretty trivial to raise this limit if you have source; mostly just changing a few parameters in /sys/h/dmap.h around: DMMIN, DMMAX, DMTEXT, and NXDAD. Unfortunately, the proper values to change them to are not intuitively obvious, and will depend upon subtle things like the size of your swap space, etc. Another not so obvious problem with this is that if your 200 MB program core dumps, your disks will fill up in a hurry! We got around this by not doing core dumps for programs > 32 MB unless the user had done the appropriate setrlimit call first. This helps, but still isn't a perfect solution. Yet another problem is that it takes a LONG time to run out of stack space when running an infinitely recursive program if you allow 100 MB of stack! We kept the default stack limit of 1/2 MB, again settable via setrlimit, and only rarely run into cases where the default's not enough. Oddly enough, fsck was one of the things which ran out of stack! Doug Hosking Convex Computer Corp. Richardson, TX {allegra, ihnp4,uiucdcs}!convex!convexs!hosking