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: 103376,151c5b24f1d7dc7
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1995-02-23 02:27:47 PST
Path: 
 nntp.gmd.de!stern.fokus.gmd.de!gmdtub!cs.tu-berlin.de!fu-berlin.de!news.dfn.de!swiss.ans.net!howland.reston.ans.net!pipex!oleane!jussieu.fr!univ-lyon1.fr!swidir.switch.ch!epflnews!dinews.epfl.ch!lglsun!nebbe
From: nebbe@lglsun.epfl.ch (Robb Nebbe)
Newsgroups: comp.lang.ada
Subject: Re: object allocation: Mach, zones, ADA and C++
Message-ID: <1995Feb23.090017@lglsun.epfl.ch>
Date: 23 Feb 95 10:27:47 GMT
References: <GBOL.95Feb19102202@custard.think.com>
Sender: nebbe@lglsun3.epfl.ch (Robb Nebbe)
Organization: Ecole Polytechnique Federale de Lausanne
NNTP-Posting-Host: lglsun3.epfl.ch
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: 1995-02-23T10:27:47+00:00
List-Id: <comp.lang.ada>

In article <GBOL.95Feb19102202@custard.think.com>,
gbol@custard.think.com (Gregory Lampshire) writes:

The problem:

|> I want to allocate an object and other record members of that object from
|> the same zone under a Mach based operating system. ...
 
|> I would like to use zone based allocation in Ada for objects (and more
|> importantly, tagged objects) but it is not clear how to control the
|> allocation at the level that I wish.  


proposed C++ solution:

|> Under C++, I would define a class
|> member function ``new'' which allows me to control which zone to use.  For
|> example in C++, I could define
|> 
|> void* T::operator new(size_t n, Zone z)
|> 
|> and do a
|> 
|> t = new(zone(s)) T;

I really don't see any difficulty in doing this in Ada but I don't
have enough information to suggest a complete solution.

What is the correspondance between zones and memory pools and why?

You seem to imply that you would naturally use one memory pool per
zone. In this case you write a function that takes a zone parameter
and allocates an object, returning a general access type to the
object.

If zones all share the same address space a better solution might
be dividing a single memory pool into different zones. You could
add an operation that returns the zone to which a access type
provides access and implement this in the pool rather than in each
object.

If zones are something important in Mach a zoned_pool type might
make a lot of sense from a reusability point of view.

I don't understand the problem well enough so I'm just guessing but
if you want to provide more information I'd be happy to continue
guessing :-)

Robb Nebbe