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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e80a1497a689d8a5 X-Google-Attributes: gid103376,public From: Wes Groleau Subject: Re: Ammo-zilla Date: 1999/11/03 Message-ID: <3820B169.C0F1DD1A@ftw.rsc.raytheon.com>#1/1 X-Deja-AN: 544127361 Content-Transfer-Encoding: 7bit References: <38120FAF.945ADD7D@hso.link.com> <7uutgd$87h$1@nnrp1.deja.com> <19991024.18033546@db3.max5.com> <38189268.43EB150F@mail.earthlink.net> <86ogdjtdwz.fsf@ppp-115-70.villette.club-internet.fr> <7vadsp$8q61@news.cis.okstate.edu> <1999Oct28.221910.1@eisner> <7vb3c4$8a21@news.cis.okstate.edu> <7vc2er$128q$1@news.gate.net> <7vco1c$ohs@drn.newsguy.com> <7vhg5c$7i9$1@nnrp1.deja.com> <381F5D4E.DA02015B@mail.earthlink.net> X-Accept-Language: en,es,fr,pt Content-Type: text/plain; charset=us-ascii X-Complaints-To: news@icg.raytheon.com X-Trace: bos-service2.ext.raytheon.com 941666675 151.168.144.162 (Wed, 03 Nov 1999 16:04:35 CST) Organization: Raytheon Company MIME-Version: 1.0 NNTP-Posting-Date: Wed, 03 Nov 1999 16:04:35 CST Newsgroups: comp.lang.ada Date: 1999-11-03T00:00:00+00:00 List-Id: > I believe this to be a -um- "valid" claim. According to the reports > that I have heard, the Java (Sun, which version?) garbage collector > would collect garbage internally, but would never return the allocated / > collected space back to the operating system. This would cause the > program to develop a very slow "leak". I don't know how serious this > ever became (or, actually, even whether this was true) but this was the > claim. So, in some sense, it never did collect and free any memory, > although the program was able to re-use it. This was true of one Ada RTS five years ago, and a current user recently told me it's still true. The vendor offered us as a "fix" a file containing a pragma that made "new" and unch. deall. call malloc and free, respectively! In fact, this vendor's RTS was even worse--free list was never defragmented (coalesced, whatever you want to call it) so that if your allocations varied in size much, you would eventually have NO blocks big enough for another allocation.