1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD>
<TITLE>AARM95 - Storage Management</TITLE>
<META NAME="Author" CONTENT="JTC1/SC22/WG9/ARG, by Randall Brukardt, ARG Editor">
<META NAME="GENERATOR" CONTENT="Arm_Form.Exe, Ada Reference Manual generator">
<STYLE type="text/css">
DIV.paranum {position: absolute; font-family: Arial, Helvetica, sans-serif; left: 0.5 em; top: auto}
TT {font-family: "Courier New", monospace}
DT {display: compact}
DIV.Normal {font-family: "Times New Roman", Times, serif; margin-bottom: 0.6em}
DIV.Wide {font-family: "Times New Roman", Times, serif; margin-top: 0.6em; margin-bottom: 0.6em}
DIV.Annotations {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-bottom: 0.6em}
DIV.WideAnnotations {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-top: 0.6em; margin-bottom: 0.6em}
DIV.Index {font-family: "Times New Roman", Times, serif}
DIV.SyntaxSummary {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-bottom: 0.4em}
DIV.Notes {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-bottom: 0.6em}
DIV.NotesHeader {font-family: "Times New Roman", Times, serif; margin-left: 2.0em}
DIV.SyntaxIndented {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-bottom: 0.4em}
DIV.Indented {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-bottom: 0.6em}
DIV.CodeIndented {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-bottom: 0.6em}
DIV.SmallIndented {font-family: "Times New Roman", Times, serif; margin-left: 10.0em; margin-bottom: 0.6em}
DIV.SmallCodeIndented {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-bottom: 0.6em}
DIV.Examples {font-family: "Courier New", monospace; margin-left: 2.0em; margin-bottom: 0.6em}
DIV.SmallExamples {font-family: "Courier New", monospace; font-size: 80%; margin-left: 7.5em; margin-bottom: 0.6em}
DIV.IndentedExamples {font-family: "Courier New", monospace; margin-left: 8.0em; margin-bottom: 0.6em}
DIV.SmallIndentedExamples {font-family: "Courier New", monospace; font-size: 80%; margin-left: 15.0em; margin-bottom: 0.6em}
UL.Bulleted {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-right: 2.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.SmallBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.NestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.SmallNestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-right: 8.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.IndentedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-right: 8.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.CodeIndentedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.CodeIndentedNestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-right: 8.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.SyntaxIndentedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.NotesBulleted {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.NotesNestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
DL.Hanging {font-family: "Times New Roman", Times, serif; margin-top: 0em; margin-bottom: 0.6em}
DD.Hanging {margin-left: 6.0em}
DL.IndentedHanging {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-top: 0em; margin-bottom: 0.6em}
DD.IndentedHanging {margin-left: 2.0em}
DL.HangingInBulleted {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-right: 2.0em; margin-top: 0em; margin-bottom: 0.5em}
DD.HangingInBulleted {margin-left: 4.0em}
DL.SmallHanging {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-top: 0em; margin-bottom: 0.6em}
DD.SmallHanging {margin-left: 7.5em}
DL.SmallIndentedHanging {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-top: 0em; margin-bottom: 0.6em}
DD.SmallIndentedHanging {margin-left: 2.0em}
DL.SmallHangingInBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
DD.SmallHangingInBulleted {margin-left: 5.0em}
DL.Enumerated {font-family: "Times New Roman", Times, serif; margin-right: 0.0em; margin-top: 0em; margin-bottom: 0.5em}
DD.Enumerated {margin-left: 2.0em}
DL.SmallEnumerated {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
DD.SmallEnumerated {margin-left: 2.5em}
DL.NestedEnumerated {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-right: 2.0em; margin-top: 0em; margin-bottom: 0.5em}
DL.SmallNestedEnumerated {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
</STYLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFF0" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">
<P><A HREF="AA-TOC.html">Contents</A> <A HREF="AA-0-29.html">Index</A> <A HREF="AA-13-10.html">Previous</A> <A HREF="AA-13-11-1.html">Next</A></P>
<HR>
<H1> 13.11 Storage Management</H1>
<DIV Class="Paranum"><FONT SIZE=-2>1</FONT></DIV>
<DIV Class="Normal"> [ <A NAME="I4625"></A><A NAME="I4626"></A><A NAME="I4627"></A><A NAME="I4628"></A>Each
access-to-object type has an associated storage pool. The storage allocated
by an <FONT FACE="Arial, Helvetica">allocator</FONT> comes from the pool;
instances of Unchecked_Deallocation return storage to the pool. Several
access types can share the same pool.]</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>2</FONT></DIV>
<DIV Class="Normal"> [A storage pool is a variable of a type in the
class rooted at Root_Storage_Pool, which is an abstract limited controlled
type. By default, the implementation chooses a <I>standard storage pool</I>
for each access type. The user may define new pool types, and may override
the choice of pool for an access type by specifying Storage_Pool for
the type.] </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>2.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>By default,
the implementation might choose to have a single global storage pool,
which is used (by default) by all access types, which might mean that
storage is reclaimed automatically only upon partition completion. Alternatively,
it might choose to create a new pool at each accessibility level, which
might mean that storage is reclaimed for an access type when leaving
the appropriate scope. Other schemes are possible. </FONT></DIV>
<H4 ALIGN=CENTER>Legality Rules</H4>
<DIV Class="Paranum"><FONT SIZE=-2>3</FONT></DIV>
<DIV Class="Normal"> If Storage_Pool is specified for a given access
type, Storage_Size shall not be specified for it. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>3.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>The Storage_Pool
determines the Storage_Size; hence it would not make sense to specify
both. Note that this rule is simplified by the fact that the aspects
in question cannot be specified for derived types, nor for non-first
subtypes, so we don't have to worry about whether, say, Storage_Pool
on a derived type overrides Storage_Size on the parent type. For the
same reason, ``specified'' means the same thing as ``directly specified''
here. </FONT></DIV>
<H4 ALIGN=CENTER>Static Semantics</H4>
<DIV Class="Paranum"><FONT SIZE=-2>4</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em"> The following language-defined
library package exists: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>5</FONT></DIV>
<DIV Class="Examples"><TT><B>with</B> Ada.Finalization;<BR>
<B>with</B> System.Storage_Elements;<BR>
<A NAME="I4629"></A><A NAME="I4630"></A><A NAME="I4631"></A><B>package</B> System.Storage_Pools <B>is</B><BR>
<B>pragma</B> Preelaborate(System.Storage_Pools);</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>6</FONT></DIV>
<DIV Class="Examples"><TT> <B>type</B> <A NAME="I4632"></A><A NAME="I4633"></A>Root_Storage_Pool <B>is</B><BR>
<B>abstract</B> <B>new</B> Ada.Finalization.Limited_Controlled <B>with</B> <B>private</B>;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>7</FONT></DIV>
<DIV Class="Examples"><TT> <B>procedure</B> <A NAME="I4634"></A><A NAME="I4635"></A>Allocate(<BR>
Pool : <B>in</B> <B>out</B> Root_Storage_Pool;<BR>
Storage_Address : <B>out</B> Address;<BR>
Size_In_Storage_Elements : <B>in</B> Storage_Elements.Storage_Count;<BR>
Alignment : <B>in</B> Storage_Elements.Storage_Count) <B>is</B> <B>abstract</B>;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>8</FONT></DIV>
<DIV Class="Examples"><TT> <B>procedure</B> <A NAME="I4636"></A><A NAME="I4637"></A>Deallocate(<BR>
Pool : <B>in</B> <B>out</B> Root_Storage_Pool;<BR>
Storage_Address : <B>in</B> Address;<BR>
Size_In_Storage_Elements : <B>in</B> Storage_Elements.Storage_Count;<BR>
Alignment : <B>in</B> Storage_Elements.Storage_Count) <B>is</B> <B>abstract</B>;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9</FONT></DIV>
<DIV Class="Examples"><TT> <B>function</B> <A NAME="I4638"></A><A NAME="I4639"></A>Storage_Size(Pool : Root_Storage_Pool)<BR>
<B>return</B> Storage_Elements.Storage_Count <B>is</B> <B>abstract</B>;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>10</FONT></DIV>
<DIV Class="Examples"><TT><B>private</B><BR>
... -- <I>not specified by the language</I><BR>
<B>end</B> System.Storage_Pools;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>10.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>The Alignment parameter
is provided to Deallocate because some allocation strategies require
it. If it is not needed, it can be ignored. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11</FONT></DIV>
<DIV Class="Normal"> <A NAME="I4640"></A><A NAME="I4641"></A>A <I>storage
pool type</I> (or <I>pool type</I>) is a descendant of Root_Storage_Pool.
<A NAME="I4642"></A><A NAME="I4643"></A><A NAME="I4644"></A>The <I>elements</I>
of a storage pool are the objects allocated in the pool by <FONT FACE="Arial, Helvetica">allocator</FONT>s.
</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>In most cases,
an element corresponds to a single memory block allocated by Allocate.
However, in some cases the implementation may choose to associate more
than one memory block with a given pool element. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>12/1</FONT></DIV>
<DIV Class="Normal"> {<I><A HREF="defect1.html#8652/0009">8652/0009</A></I>}
For every access subtype S, the following <U>representation </U>attributes
are defined: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>13</FONT></DIV>
<DL Class="Hanging"><DT> S'Storage_Pool<DD Class="Hanging">
<A NAME="I4645"></A><A NAME="I4646"></A>Denotes the storage pool of the
type of S. The type of this attribute is Root_Storage_Pool'Class.</DL>
<DIV Class="Paranum"><FONT SIZE=-2>14</FONT></DIV>
<DL Class="Hanging"><DT> S'Storage_Size<DD Class="Hanging">
<A NAME="I4647"></A><A NAME="I4648"></A>Yields the result of calling
Storage_Size(S'Storage_Pool)[, which is intended to be a measure of the
number of storage elements reserved for the pool.] The type of this attribute
is <I>universal_integer</I>. </DL>
<DIV Class="Paranum"><FONT SIZE=-2>14.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>Storage_Size
is also defined for task subtypes and objects -- see <A HREF="AA-13-3.html">13.3</A>.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>14.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Storage_Size is not a measure
of how much un-allocated space is left in the pool. That is, it includes
both allocated and unallocated space. Implementations and users may provide
a Storage_Available function for their pools, if so desired. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>15</FONT></DIV>
<DIV Class="Normal"> <A NAME="I4649"></A><A NAME="I4650"></A><A NAME="I4651"></A><A NAME="I4652"></A>Storage_Size
or Storage_Pool may be specified for a non-derived access-to-object type
via an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>;
the <FONT FACE="Arial, Helvetica">name</FONT> in a Storage_Pool clause
shall denote a variable.</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>16</FONT></DIV>
<DIV Class="Normal"> An <FONT FACE="Arial, Helvetica">allocator</FONT>
of type T allocates storage from T's storage pool. If the storage pool
is a user-defined object, then the storage is allocated by calling Allocate,
passing T'Storage_Pool as the Pool parameter. The Size_In_Storage_Elements
parameter indicates the number of storage elements to be allocated, and
is no more than D'Max_Size_In_Storage_Elements, where D is the designated
subtype. The Alignment parameter is D'Alignment. <A NAME="I4653"></A><A NAME="I4654"></A>The
result returned in the Storage_Address parameter is used by the <FONT FACE="Arial, Helvetica">allocator</FONT>
as the address of the allocated storage, which is a contiguous block
of memory of Size_In_Storage_Elements storage elements. [Any exception
propagated by Allocate is propagated by the <FONT FACE="Arial, Helvetica">allocator</FONT>.]
</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>16.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>If the implementation
chooses to represent the designated subtype in multiple pieces, one <FONT FACE="Arial, Helvetica">allocator</FONT>
evaluation might result in more than one call upon Allocate. In any case,
<FONT FACE="Arial, Helvetica">allocator</FONT>s for the access type obtain
all the required storage for an object of the designated type by calling
the specified Allocate procedure.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>16.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Note that the implementation does
not turn other exceptions into Storage_Error.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>16.b.1/1</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>{<I><A HREF="defect2.html#8652/0111">8652/0111</A></I>}
<U>If D (the designated type of T) includes subcomponents of other access
types, they will be allocated from the storage pools for those types,
even if those <FONT FACE="Arial, Helvetica">allocator</FONT>s are executed
as part of the <FONT FACE="Arial, Helvetica">allocator</FONT> of T (as
part of the initialization of the object). For instance, an access-to-task
type TT may allocate the data structures used to implement the task value
from other storage pools. (In particular, the task stack does not necessarily
need to be allocated from the storage pool for TT.)</U> </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>17</FONT></DIV>
<DIV Class="Normal"> <A NAME="I4655"></A>If Storage_Pool is not specified
for a type defined by an <FONT FACE="Arial, Helvetica">access_to_object_definition</FONT>,
then the implementation chooses a standard storage pool for it in an
implementation-defined manner. <A NAME="I4656"></A><A NAME="I4657"></A><A NAME="I4658"></A>In
this case, the exception Storage_Error is raised by an <FONT FACE="Arial, Helvetica">allocator</FONT>
if there is not enough storage. It is implementation defined whether
or not the implementation provides user-accessible names for the standard
pool type(s). </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>17.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation defined: </B>The
manner of choosing a storage pool for an access type when Storage_Pool
is not specified for the type.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>17.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation defined: </B>Whether
or not the implementation provides user-accessible names for the standard
pool type(s).</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>17.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>An anonymous
access type has no pool. An access-to-object type defined by a <FONT FACE="Arial, Helvetica">derived_type_definition</FONT>
inherits its pool from its parent type, so all access-to-object types
in the same derivation class share the same pool. Hence the ``defined
by an <FONT FACE="Arial, Helvetica">access_to_object_definition</FONT>''
wording above.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>17.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><A NAME="I4659"></A><A NAME="I4660"></A>There
is no requirement that all storage pools be implemented using a contiguous
block of memory (although each allocation returns a pointer to a contiguous
block of memory). </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>18</FONT></DIV>
<DIV Class="Normal"> If Storage_Size is specified for an access type,
then the Storage_Size of this pool is at least that requested, and the
storage for the pool is reclaimed when the master containing the declaration
of the access type is left. <A NAME="I4661"></A>If the implementation
cannot satisfy the request, Storage_Error is raised at the point of the
<FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>. If
neither Storage_Pool nor Storage_Size are specified, then the meaning
of Storage_Size is implementation defined. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>18.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation defined: </B>The
meaning of Storage_Size.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>18.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>The Storage_Size
function and attribute will return the actual size, rather than the requested
size. Comments about rounding up, zero, and negative on task Storage_Size
apply here, as well. See also AI83-00557, AI83-00558, and AI83-00608.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>18.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The expression in a Storage_Size
clause need not be static.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>18.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The reclamation happens after
the master is finalized. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>18.e</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation Note: </B>For
a pool allocated on the stack, normal stack cut-back can accomplish the
reclamation. For a library-level pool, normal partition termination actions
can accomplish the reclamation. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19</FONT></DIV>
<DIV Class="Normal"> If Storage_Pool is specified for an access type,
then the specified pool is used.</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>20</FONT></DIV>
<DIV Class="Normal"> <A NAME="I4662"></A>The effect of calling Allocate
and Deallocate for a standard storage pool directly (rather than implicitly
via an <FONT FACE="Arial, Helvetica">allocator</FONT> or an instance
of Unchecked_Deallocation) is unspecified. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>20.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>For example,
an <FONT FACE="Arial, Helvetica">allocator</FONT> might put the pool
element on a finalization list. If the user directly Deallocates it,
instead of calling an instance of Unchecked_Deallocation, then the implementation
would probably try to finalize the object upon master completion, which
would be bad news. Therefore, the implementation should define such situations
as erroneous. </FONT></DIV>
<H4 ALIGN=CENTER>Erroneous Execution</H4>
<DIV Class="Paranum"><FONT SIZE=-2>21</FONT></DIV>
<DIV Class="Normal"> <A NAME="I4663"></A>If Storage_Pool is specified
for an access type, then if Allocate can satisfy the request, it should
allocate a contiguous block of memory, and return the address of the
first storage element in Storage_Address. The block should contain Size_In_Storage_Elements
storage elements, and should be aligned according to Alignment. The allocated
storage should not be used for any other purpose while the pool element
remains in existence. If the request cannot be satisfied, then Allocate
should propagate an exception [(such as Storage_Error)]. If Allocate
behaves in any other manner, then the program execution is erroneous.
</DIV>
<H4 ALIGN=CENTER>Documentation Requirements</H4>
<DIV Class="Paranum"><FONT SIZE=-2>22</FONT></DIV>
<DIV Class="Normal"> An implementation shall document the set of values
that a user-defined Allocate procedure needs to accept for the Alignment
parameter. An implementation shall document how the standard storage
pool is chosen, and how storage is allocated by standard storage pools.
</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>22.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation defined: </B>Implementation-defined
aspects of storage pools.</FONT></DIV>
<H4 ALIGN=CENTER>Implementation Advice</H4>
<DIV Class="Paranum"><FONT SIZE=-2>23</FONT></DIV>
<DIV Class="Normal"> An implementation should document any cases in
which it dynamically allocates heap storage for a purpose other than
the evaluation of an <FONT FACE="Arial, Helvetica">allocator</FONT>.
</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>23.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>This is ``Implementation
Advice'' because the term ``heap storage'' is not formally definable;
therefore, it is not testable whether the implementation obeys this advice.
</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24</FONT></DIV>
<DIV Class="Normal"> A default (implementation-provided) storage pool
for an access-to-constant type should not have overhead to support deallocation
of individual objects. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>Unchecked_Deallocation
is not defined for such types. If the access-to-constant type is library-level,
then no deallocation (other than at partition completion) will ever be
necessary, so if the size needed by an <FONT FACE="Arial, Helvetica">allocator</FONT>
of the type is known at link-time, then the allocation should be performed
statically. If, in addition, the initial value of the designated object
is known at compile time, the object can be allocated to read-only memory.
</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation Note: </B>If
the Storage_Size for an access type is specified, the storage pool should
consist of a contiguous block of memory, possibly allocated on the stack.
The pool should contain approximately this number of storage elements.
These storage elements should be reserved at the place of the Storage_Size
clause, so that <FONT FACE="Arial, Helvetica">allocator</FONT>s cannot
raise Storage_Error due to running out of pool space until the appropriate
number of storage elements has been used up. This approximate (possibly
rounded-up) value should be used as a maximum; the implementation should
not increase the size of the pool on the fly. If the Storage_Size for
an access type is specified as zero, then the pool should not take up
any storage space, and any <FONT FACE="Arial, Helvetica">allocator</FONT>
for the type should raise Storage_Error. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>Note that
most of this is approximate, and so cannot be (portably) tested. That's
why we make it an Implementation Note. There is no particular number
of allocations that is guaranteed to succeed, and there is no particular
number of allocations that is guaranteed to fail. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>25</FONT></DIV>
<DIV Class="Normal"> A storage pool for an anonymous access type should
be created at the point of an allocator for the type, and be reclaimed
when the designated object becomes inaccessible. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>25.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation Note: </B>Normally
the "storage pool" for an anonymous access type would not exist
as a separate entity. Instead, the designated object of the allocator
would be allocated, in the case of an access parameter, as a local aliased
variable at the call site, and in the case of an access discriminant,
contiguous with the object containing the discriminant. This is similar
to the way storage for <FONT FACE="Arial, Helvetica">aggregate</FONT>s
is typically managed. </FONT></DIV>
<DIV Class="NotesHeader"><FONT SIZE=-1>NOTES</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>26</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>23 A user-defined storage
pool type can be obtained by extending the Root_Storage_Pool type, and
overriding the primitive subprograms Allocate, Deallocate, and Storage_Size.
A user-defined storage pool can then be obtained by declaring an object
of the type extension. The user can override Initialize and Finalize
if there is any need for non-trivial initialization and finalization
for a user-defined pool type. For example, Finalize might reclaim blocks
of storage that are allocated separately from the pool object itself.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>27</FONT></DIV>
<DIV Class="Notes" Style="margin-bottom: 0.4em"><FONT SIZE=-1>24 The
writer of the user-defined allocation and deallocation procedures, and
users of <FONT FACE="Arial, Helvetica">allocator</FONT>s for the associated
access type, are responsible for dealing with any interactions with tasking.
In particular: </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>28</FONT></DIV>
<UL Class="NotesBulleted"><FONT SIZE=-1><LI TYPE=DISC>If the <FONT FACE="Arial, Helvetica">allocator</FONT>s
are used in different tasks, they require mutual exclusion.</LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>29</FONT></DIV>
<UL Class="NotesBulleted"><FONT SIZE=-1><LI TYPE=DISC>If they are used inside protected objects, they cannot
block.</LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>30</FONT></DIV>
<UL Class="NotesBulleted"><FONT SIZE=-1><LI TYPE=DISC>If they are used by interrupt handlers (see <A HREF="AA-C-3.html">C.3</A>,
``<A HREF="AA-C-3.html">Interrupt Support</A>''), the mutual exclusion
mechanism has to work properly in that context. </LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>31</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>25 The primitives Allocate,
Deallocate, and Storage_Size are declared as abstract (see <A HREF="AA-3-9-3.html">3.9.3</A>),
and therefore they have to be overridden when a new (non-abstract) storage
pool type is declared. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>31.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>Note that
the Storage_Pool attribute denotes an object, rather than a value, which
is somewhat unusual for attributes.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>31.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The calls to Allocate, Deallocate,
and Storage_Size are dispatching calls -- this follows from the fact
that the actual parameter for Pool is T'Storage_Pool, which is of type
Root_Storage_Pool'Class. In many cases (including all cases in which
Storage_Pool is not specified), the compiler can determine the tag statically.
However, it is possible to construct cases where it cannot.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>31.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>All access types in the same derivation
class share the same pool, whether implementation defined or user defined.
This is necessary because we allow type conversions among them (even
if they are pool-specific), and we want pool-specific access values to
always designate an element of the right pool. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>31.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation Note: </B>If
an access type has a standard storage pool, then the implementation doesn't
actually have to follow the pool interface described here, since this
would be semantically invisible. For example, the allocator could conceivably
be implemented with inline code. </FONT></DIV>
<H4 ALIGN=CENTER>Examples</H4>
<DIV Class="Paranum"><FONT SIZE=-2>32</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em"> To associate an
access type with a storage pool object, the user first declares a pool
object of some type derived from Root_Storage_Pool. Then, the user defines
its Storage_Pool attribute, as follows:</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>33</FONT></DIV>
<DIV Class="Examples"><TT>Pool_Object : Some_Storage_Pool_Type;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>34</FONT></DIV>
<DIV Class="Examples"><TT><B>type</B> T <B>is</B> <B>access</B> Designated;<BR>
<B>for</B> T'Storage_Pool <B>use</B> Pool_Object;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>35</FONT></DIV>
<DIV Class="Wide" Style="margin-bottom: 0.4em"> Another access type
may be added to an existing storage pool, via: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>36</FONT></DIV>
<DIV Class="Examples"><TT><B>for</B> T2'Storage_Pool <B>use</B> T'Storage_Pool;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>37</FONT></DIV>
<DIV Class="Normal"> The semantics of this is implementation defined
for a standard storage pool. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>37.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>For example, the
implementation is allowed to choose a storage pool for T that takes advantage
of the fact that T is of a certain size. If T2 is not of that size, then
the above will probably not work. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>38</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em"> As usual, a derivative
of Root_Storage_Pool may define additional operations. For example, presuming
that Mark_Release_Pool_Type has two additional operations, Mark and Release,
the following is a possible use: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>39/1</FONT></DIV>
<DIV Class="Examples"><TT>{<I><A HREF="defect1.html#8652/0041">8652/0041</A></I>}
<BR>
<B>type</B> Mark_Release_Pool_Type<BR>
(Pool_Size : Storage_Elements.Storage_Count;<BR>
Block_Size : Storage_Elements.Storage_Count)<BR>
<B>is</B> <B>new</B> Root_Storage_Pool <B>with <S>limited </S>private</B>;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>40</FONT></DIV>
<DIV Class="Examples"><TT>...</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>41</FONT></DIV>
<DIV Class="Examples"><TT>MR_Pool : Mark_Release_Pool_Type (Pool_Size => 2000,<BR>
Block_Size => 100);</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>42</FONT></DIV>
<DIV Class="Examples"><TT><B>type</B> Acc <B>is</B> <B>access</B> ...;<BR>
<B>for</B> Acc'Storage_Pool <B>use</B> MR_Pool;<BR>
...</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>43</FONT></DIV>
<DIV Class="Examples"><TT>Mark(MR_Pool);<BR>
... --<I> Allocate objects using ``<B>new</B> Designated(...)''.</I><BR>
Release(MR_Pool); --<I> Reclaim the storage.</I></TT></DIV>
<H4 ALIGN=CENTER>Extensions to Ada 83</H4>
<DIV Class="Paranum"><FONT SIZE=-2>43.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><A NAME="I4664"></A>User-defined
storage pools are new to Ada 95. </FONT></DIV>
<H4 ALIGN=CENTER>Wording Changes from Ada 83</H4>
<DIV Class="Paranum"><FONT SIZE=-2>43.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Ada 83 had a concept called a
``collection,'' which is similar to what we call a storage pool. All
access types in the same derivation class shared the same collection.
In Ada 95, all access types in the same derivation class share the same
storage pool, but other (unrelated) access types can also share the same
storage pool, either by default, or as specified by the user. A collection
was an amorphous collection of objects; a storage pool is a more concrete
concept -- hence the different name.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>43.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>RM83 states the erroneousness
of reading or updating deallocated objects incorrectly by missing various
cases. </FONT></DIV>
<HR>
<P><A HREF="AA-TOC.html">Contents</A> <A HREF="AA-0-29.html">Index</A> <A HREF="AA-13-10.html">Previous</A> <A HREF="AA-13-11-1.html">Next</A> <A HREF="AA-TTL.html">Legal</A></P>
</BODY>
</HTML>
|
