From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10ad19,23963231b5359f74 X-Google-Attributes: gid10ad19,public X-Google-Thread: 101deb,23963231b5359f74 X-Google-Attributes: gid101deb,public X-Google-Thread: 103376,23963231b5359f74 X-Google-Attributes: gid103376,public X-Google-Thread: 1073c2,23963231b5359f74 X-Google-Attributes: gid1073c2,public X-Google-Thread: 107a89,23963231b5359f74 X-Google-Attributes: gid107a89,public X-Google-Thread: 10a146,23963231b5359f74 X-Google-Attributes: gid10a146,public X-Google-ArrivalTime: 2001-06-10 06:04:58 PST Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!sn-xit-04!supernews.com!newsfeed.mesh.ad.jp!sjc-peer.news.verio.net!news.verio.net!iad-read.news.verio.net.POSTED!kilgallen From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) Newsgroups: comp.lang.ada,comp.lang.awk,comp.lang.clarion,comp.lang.java.programmer,comp.lang.pl1,comp.lang.vrml Subject: Re: Memory Allocation without pointer arithmetic ? (was: Long names...) Message-ID: References: <9f2nks$ibd$0@dosa.alt.net> <3B177EF7.2A2470F4@facilnet.es> <9f8b7b$h0e$1@nh.pace.co.uk> <9f8r0i$lu3$1@nh.pace.co.uk> <9fgagu$6ae$1@nh.pace.co.uk> <9fjgha$blf$1@nh.pace.co.uk> <35mqhtkdfma2rggv1htcaq6vfn2ihs67a1@4ax.com> <9fli1b$4aa$1@nh.pace.co.uk> In article <3B221877.BBE3A49F@acm.org>, Patricia Shanahan writes: > > > Larry Kilgallen wrote: >> >> In article <3B219DB3.4BF2A68A@acm.org>, Patricia Shanahan writes: >> > James Kanze wrote: >> >> >> >> Pete Thompson wrote: >> >> >> >> [...] >> >> > Well, sure. Pointer arithmetic in C/C++ is inherently unsafe and >> >> > encourages obfuscation. However, it also promotes flexibility. >> >> >> >> Just curious, but what can you do with pointer arithmetic in C/C++ >> >> that you couldn't do otherwise, in a cleaner fashion? >> > ... >> > >> > Manage memory. A memory allocator, such as malloc, or the corresponding >> > kernel code, or the code underlying "new", has a split view of memory. >> > It must perform calcuations to determine where to put the the newly >> > created object. It must return a pointer to it. >> >> That is an interesting example, even though it should only occur once >> per operating system. I have never tried to do that in Ada. > > I would expect a few times per OS. For example: > > 1. User malloc. That can also be the function underlying "new" in C++. > > 2. Implementation of Java "new". While I suppose it may be based on > malloc, there may be additional requirements to support GC making it > different. The fact that the Java heap has a predetermined size limit > suggests that it is separate, because the malloc space is supposed to > grow as big as the OS will let it. The underlying allocation mechanism on the operating system with which I am most familiar has an optional size limit. I don't know whether Java uses it or not, since I am not a Java person, but it does not _need_ to have a separate implementation (of the pointer arithmetic part). GC is "just" a matter of deciding when to deallocate the memory, nothing inherent in the pointer arithmetic part. > 3. Kernel equivalent of malloc. It can use similar algorithms to malloc, > but will need different handling when it runs out of currently available > memory. This may be subdivided depending on whether the allocations can > be pageable or not. Actions in the case of failure are outside the scope of the memory allocation mechanism. I could decide to have my (suitably privileged) user mode program crash the machine in the event of failure. Running two (or more) allocation pools does not require separate allocation code -- just a pool choice parameter. > 4. Kernel buffer allocation. The kernel will need to allocate a lot of > buffers whose sizes will be multiples of a moderately large power of > two. It may be more efficient to use a different allocation system > rather than throwing them into the main kernel pool. I did not mean to imply that the single allocation implementation should not support lookaside lists (as an option) or in any other sense be built with "least common denominator" features. So my question stands: >> Does anyone have experience trying to subdivide memory objects (the >> free pool) without using the equivalent of pointer arithmetic ?