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: 107a89,23963231b5359f74 X-Google-Attributes: gid107a89,public X-Google-Thread: 101deb,23963231b5359f74 X-Google-Attributes: gid101deb,public X-Google-Thread: 10a146,23963231b5359f74 X-Google-Attributes: gid10a146,public X-Google-Thread: 103376,23963231b5359f74 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-06-10 11:33:14 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.alt.net!usenet From: "Chris Smith" Newsgroups: comp.lang.ada,comp.lang.clarion,comp.lang.java.programmer,comp.lang.pl1 Subject: Re: Memory Allocation without pointer arithmetic ? (was: Long names...) Date: Sun, 10 Jun 2001 13:24:04 -0500 Organization: Altopia Corp. - Usenet Access - http://www.altopia.com Message-ID: <9g0eh9$76j$2@pita.alt.net> 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> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:8517 comp.lang.clarion:21590 comp.lang.java.programmer:75122 comp.lang.pl1:961 Date: 2001-06-10T13:24:04-05:00 List-Id: [Groups snipped as some have requested] "Larry Kilgallen" wrote ... > > 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. The mention of heap size limits was merely to point out that it appears that Java manages its heap differently. In fact, the Sun implementation of Java does. GC implemented on top of conventional malloc() can be quite slow. Most modern garbage collectors use copying collection, which partially offsets the overhead of garbage collection when releasing memory with a far-reduced performance impact of allocation; allocation becomes bumping a pointer, analogous in performance to a stack allocation, rather than a far more expensive explicitly managed heap allocation. There are other garbage collection algorithms, such as mark/sweep, that are common implemented on top of an explicitly managed heap architecture, but IME they are mostly used for easy implementation or compatibility, and lag behind copying collectors in performance, both because of poor interactions with the memory hierarchy and because of the increase in allocation times. Chris Smith