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,9c0f2ad38cef26ed
X-Google-Attributes: gid103376,public
From: kilgallen@eisner.decus.org (Larry Kilgallen)
Subject: Re: Garbage collection (was a spinoff of a spinoff of a GA diatribe)
Date: 1996/10/23
Message-ID: <1996Oct23.173750.1@eisner>#1/1
X-Deja-AN: 191574662
x-nntp-posting-host: eisner.decus.org
references: <9610152135.AA13753@most> <54kk6g$is6$1@goanna.cs.rmit.EDU.AU>
 <54lg65$5lc@wdl1.wdl.lmco.com>
x-nntp-posting-user: KILGALLEN
x-trace: 846106676/12220
organization: LJK Software
newsgroups: comp.lang.ada
Date: 1996-10-23T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <54lg65$5lc@wdl1.wdl.lmco.com>, mab@dst17.wdl.loral.com (Mark A Biggar) writes:
> In article <54kk6g$is6$1@goanna.cs.rmit.EDU.AU> ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) writes:
>>"W. Wesley Groleau (Wes)" <wwgrol@PSESERV3.FW.HAC.COM> writes:
>>>Explicit use of the heap for non-composite objects is not often done--why
>>>would you?
>>
>>Because you don't *know* it's non-composite.
>>Ada supports information hiding, remember?
> 
> Would not a simple hueristic like "if its 'SIZE < 64 put it on the stack,
> otherwise the heap" handle this problem reasonably well?

Perhaps I have lost context, but preventing objects whose size is known
at subprogram invocation time from being on the stack just because
their size is greater than 64 bits seems like a great way to waste
both CPU cycles and locality of reference for memory.  It may not
matter in the embedded business, but some of us use virtual memory.
Stack storage is our friend, performance-wise, and cache seems a wash
between stack and heap.

Larry Kilgallen