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,9a586954b11ae008
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Overflows (lisp fixnum-bignum conversion)
Date: 1997/04/09
Message-ID: <E8CLE7.38o@world.std.com>#1/1
X-Deja-AN: 231677523
References: <1997Apr2.202514.1843@nosc.mil> <dewar.860424609@merv>
 <1997Apr7.130018.1@eisner> <dewar.860441935@merv>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 1997-04-09T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <dewar.860441935@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>For instance, in an Ada environment in a 64-bit machine, it makes perfectly
>good sense to give every task a gigabyte stack, even if you have thousands
>of tasks, but you cannot use this approach at all on a 32-bit machine.

How about this scheme for a 32-bit machine?  Reserve half the address
space for code and heap.  Give the other half to the environment task.
If a second task is created, steal half of the unused address space from
the first task.  If a third task is created, steal half of the unused
address space from the task with the biggest unused stack space.  And so
on.

Thus, you can create lots of small tasks, or a few huge ones, without
ever having to say "pragma Storage_Size".  (Of course, you can't create
a huge number of huge tasks -- but that's a limitation of the machine,
not the run-time model.)

This seems better than having a particular default size for each task's
stack.  Has anybody done it?

(As Robert says, on a 64-bit machine, you can allocate, say, 16 G of
address space to each task, and still have enough address space for
about a billion task stacks.)

- Bob