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,3498dd887729ed19 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Garbage Collection in Ada Date: 1996/10/21 Message-ID: #1/1 X-Deja-AN: 191066011 references: <01bbb910$f1e73f60$829d6482@joy.ericsson.se> <326BE660.41C6@mti.sgi.com> organization: New York University newsgroups: comp.lang.ada Date: 1996-10-21T00:00:00+00:00 List-Id: 1. The worst-case memory requirements of ANY general purpose malloc implementation are quite bad. This is a mathematical theorem. The only way to limit this is to restrict object sizes. Yes, and restricting object sizes is a common technique. Indeed going all the way and restricting object sizes to a single size completely eliminates fragmentation, but does NOT eliminate the problem of CGC hanging on to blocks that should be freed. 3. Vendors rarely specify the allocation algorithm. So it's not possible to tune for the algorithm even in nonportable code. Yes, and providing your own allocator with known characteristics is a common technique. - "Virtual origins" work fine with a conservative GC, so long as you also keep the naive pointer representation. This is likely to be cheap (at most one extra store). Actually it is a space issue more than a speed issue, it means that pointers to unconstrained arrays would need to be three words instead of two, certainly not fatal, but not space that would seem worth spending for the relatively specialized use of 3rd party CGC's.