CVS difference for ai05s/ai05-0111-1.txt

Differences between 1.10 and version 1.11
Log of other versions for file ai05s/ai05-0111-1.txt

--- ai05s/ai05-0111-1.txt	2009/12/09 00:30:43	1.10
+++ ai05s/ai05-0111-1.txt	2010/01/09 01:31:29	1.11
@@ -4755,4 +4755,354 @@
 this Amendment. So I would like to see a simple alternative that *just* contains
 the subpool stuff, and just the parts that you have in the core.
 
-****************************************************************
\ No newline at end of file
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, December 8, 2009  9:14 PM
+
+Thanks for your replies.  I understand what you are looking for.  I have a
+somewhat different goal, but your desire for a simple mark/release-like solution
+that works reasonably for heap objects of a controlled type makes sense to me.
+It feels like the dynamic master idea is the key to that.
+
+I'm still hoping for a way to get guaranteed safety from dangling references
+without the whole garbage-collection ball of wax.  Annex H seems like the right
+place for something like that, but clearly I've got some more convincing to do.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, December 8, 2009  9:55 PM
+
+By the way, I don't think the single-size-oriented storage pools would be as
+useful for subpools, since you would generally want to put all the access types
+needed to create some particular data structure into the same subpool so they
+could be easily reclaimed at one moment.
+
+In any case, the restriction about the subpools being allocated from the main
+pool only applied to a "pool-specific" access type.  It seemed important that
+all values of a pool-specific access type designate storage that ultimately
+comes from the same single storage pool.  If you don't want that restriction,
+then presumably you could just use a general access type.
+
+I'd welcome other ideas about how to handle subpools when the access type is
+pool-specific.  The big advantage of pool-specific is that you don't have to
+worry about conversions to the type.  Perhaps that is the key thing, as far as
+aliasing, and it doesn't really matter so much whether the storage is physically
+all coming from a single pool.  Each pool-specific access type is independent
+from every other pool-specific access type as far as aliasing is concerned.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, December 9, 2009  5:42 PM
+
+I am working on a revamped version of this.
+As Randy suggested, I am returning to subpools not really being storage pools in
+their own right.
+A subpool always has an associated storage pool.
+When you specify a subpool in an allocator, it is going to allocate from the
+storage pool associated with the access type, but using a different routine,
+namely "Allocate_From_Subpool."  This new routine takes all the same parameters
+as "Allocate" but in addition takes the subpool (which at this point is back to
+being a "handle" or an "ID").  The storage pool object has to decide how it
+wants to interpret the subpool handle/ID. This new operation would be declared
+in System.Subpools, along with the Root_Subpool_Manager (which is a descendant
+of Root_Storage_Pool) and Root_Subpool_Handle/ID, which is *not* a descendant of
+Root_Storage_Pool.
+
+The main reason for this change is that I realized without this,
+unchecked-deallocation was very hard to implement.  At the point of unchecked
+deallocation, you don't know the subpool and there isn't any easy way to specify
+it.  Hence, you are going to call the Deallocate routine of the associated
+storage pool.  That means that the storage pool, rather than the subpool, really
+needs to be "in charge" of the storage, so it can do the right thing on
+unchecked deallocation.
+
+Each subpool would still represent a separate "master", for the purposes of
+finalization and task waiting, so the subpool can be deallocated safely.  There
+would probably be an explicit routine for Unchecked_Deallocate_Subpool, which
+would deallocate all of the objects in the subpool, after finalizing them.  If
+any tasks were not terminable this would raise Program_Error instead.
+
+Annex H would still provide automatic safe reclamation of subpools, eliminating
+the need to call Unchecked_Deallocate_Subpool.
+
+I hope to produce a newer version before our call, but that may be wishful
+thinking.  Hopefully this is enough information to allow us to discuss it a bit
+in any case.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, December 9, 2009  10:44 PM
+
+> By the way, I don't think the single-size-oriented storage pools would
+> be as useful for subpools, since you would generally want to put all
+> the access types needed to create some particular data structure into
+> the same subpool so they could be easily reclaimed at one moment.
+
+Maybe, maybe not. I recently used such a pool in a (futile) attempt to find a
+(supposed) dangling point problem. The data structure was a linked list of lines
+in an e-mail message, attached to a header. The line records are all of a fixed
+size record type. The list is freed all at once when the message has been
+successfully sent (or deleted). That required a loop of Unchecked_Deallocation
+calls.
+
+I could imagine using a subpool to represent the list, so that only a single
+call would be needed to free the entire list. In that case, the subpool object
+for the list would live in the header of the message. The header couldn't be
+allocated from that subpool (it wouldn't exist until the header was allocated
+and initialized - the standard chicken and egg problem that happens for
+allocated data structures). So a single-sized pool would work fine in that case.
+(The header is only a single object, so there wouldn't be any benefit to using a
+subpool for it.)
+
+> In any case, the restriction about the subpools being allocated from
+> the main pool only applied to a "pool-specific" access type.  It
+> seemed important that all values of a pool-specific access type
+> designate storage that ultimately comes from the same single storage
+> pool.  If you don't want that restriction, then presumably you could
+> just use a general access type.
+
+I still don't understand what you mean by "allocated from the main pool".
+Surely the storage for objects allocated from a subpool comes from the
+underlying storage pool. But that just means that the subpool "belongs" (for the
+lack of a better word) to the pool. And the subpool object (whatever that is)
+needn't have any relationship to the main pool other than the "belongs"
+relationship -- it shouldn't matter where its memory (which is just accounting
+data structures, if any) exists. It seems perfectly reasonable for that to be on
+the stack, or in some other data type (as in my previous example). Only
+allocated memory has to come from the main pool.
+
+It is very important to avoid confusing those issues -- it's a common confusion
+for plain old storage pools, too. (It's reasonable for a pool to get its
+allocated memory from the main heap, but still have data structures that exist
+elsewhere for dangling pointer detection or fragmentation monitoring or size
+profiling or whatever.)
+
+> I'd welcome other ideas about how to handle subpools when the access
+> type is pool-specific.  The big advantage of pool-specific is that you
+> don't have to worry about conversions to the type.  Perhaps that is
+> the key thing, as far as aliasing, and it doesn't really matter so
+> much whether the storage is physically all coming from a single pool.
+> Each pool-specific access type is independent from every other
+> pool-specific access type as far as aliasing is concerned.
+
+I think your original model is OK, it is just described bizarrely. The subpool
+has to "belong" to the pool that is specified for the type. But that doesn't
+imply anything about where it is allocated!
+
+Repeating a previous comment: Keep in mind that now that you put much of the
+semantics into Annex H, the remaining part in the core has to make sense even
+for an implementation that doesn't implement Annex H. That's my main focus right
+now; once we get that right, we can decide whether your Annex H facilities are
+really worthwhile (or whether a reasonable facsimile can be constructed by the
+end user).
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Thursday, December 31, 2009  12:29 PM
+
+> Modify 4.8(2) as follows:
+>
+> allocator ::=
+>    new [subpool_specification] subtype_indication
+>  | new [subpool_specification] qualified_expression
+>
+> subpool_specification ::= '(' subpool_name ')'
+>
+> subpool_name ::= name | implicit_dereference
+
+I hate to comment on the syntax when there would be many interesting aspects of
+the semantics to discuss, but I have read several versions of this proposal, I
+thought that I would get used to the syntax, but I don't, it's just
+disgggusting.
+
+To be frank, I have never been happy with the syntax of allocators.  A
+subtype_indication and a qualified_expression are very different things, and
+there's only that little quote to distinguish them.  I'm ready to bet that most
+users cannot really tell the difference between the two, but anyway, that's
+water under the bridge.
+
+And then Tuck is throwing the subpool in the middle of the syntax, wrapping it
+in parens just to make sure that it's even more complicated to visually tell
+which is which.  And furthermore, he is putting it first, as if it were the
+important part of the allocator.  Could we please please please have a syntax
+that gives the reader a clue about the semantics of the construct?
+
+My first idea was:
+
+  X := new String(1..5) in Subpool;
+
+But yeah, this doesn't work, there must be a million usages of membership tests
+for allocators out there.  So without further ado let me try other (combinations
+of) reserved words:
+
+  X := new String(1..5) at Subpool;
+  X := new String(1..5) use Subpool;
+  X := new String(1..5) with Subpool;
+  X := new String(1..5) out of Subpool;
+
+The latter has my preference, but then I'm not sure which one reads better for a
+native speaker of English.  At any rate, they all seem better at conveying the
+semantics than Tuck's proposed syntax.
+
+This being said I rather like the notion of subpool: I have always be frustrated
+by storage management in Ada, and this looks like a nice mechanism to improve
+both the usability and the safety of the language.  Oh, and I would drop the
+annex H stuff or move it to a separate AI that can later be killed quietly: Tuck
+was clearly smoking something when he wrote that part.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, December 31, 2009  3:19 PM
+
+> To be frank, I have never been happy with the syntax of allocators.  A
+> subtype_indication and a qualified_expression are very different
+> things, and there's only that little quote to distinguish them.  I'm
+> ready to bet that most users cannot really tell the difference between
+> the two, but anyway, that's water under the bridge.
+
+Agreed.  I'd prefer a qualified expression looked like "T(X)", and a type
+conversion looked like "convert(X, T)". Or maybe "T(convert(T2(X))" -- here,
+"convert" is a magic operation that requires its operand to be a qualified
+expression, and must be the operand of a qualified expression, so you can easily
+tell what you're converting from and to.
+
+> And then Tuck is throwing the subpool in the middle of the syntax,
+> wrapping it in parens just to make sure that it's even more
+> complicated to visually tell which is which.  And furthermore, he is
+> putting it first, as if it were the important part of the allocator.
+> Could we please please please have a syntax that gives the reader a clue about
+> the semantics of the construct?
+
+I don't find Tuck's proposed syntax disgggusting, or even disgusting.
+But I find your arguments persuasive, especially the part about how the pool is
+the unimportant part, so should come last.
+
+(By the way, thanks for that!  Most arguments about syntax boil down to "I like
+it", "Well I don't like it", ....  It's nice to see actual reasons articulated.
+;-) )
+
+> My first idea was:
+>
+>   X := new String(1..5) in Subpool;
+>
+> But yeah, this doesn't work, there must be a million usages of
+> membership tests for allocators out there.  So without further ado let
+> me try other (combinations of) reserved words:
+>
+>   X := new String(1..5) at Subpool;
+>   X := new String(1..5) use Subpool;
+>   X := new String(1..5) with Subpool;
+>   X := new String(1..5) out of Subpool;
+>
+> The latter has my preference, but then I'm not sure which one reads
+> better for a native speaker of English.  At any rate, they all seem
+> better at conveying the semantics than Tuck's proposed syntax.
+
+I don't particularly like any of the above (sorry, I can't articulate any
+reason).  But I could tolerate any of the above.  I guess I agree with you that
+"out of" reads best.  On the other hand, it seems annoying to have two keywords
+where one should suffice.
+
+> This being said I rather like the notion of subpool: I have always be
+> frustrated by storage management in Ada, and this looks like a nice
+> mechanism to improve both the usability and the safety of the language.
+
+Yes.
+
+>...Oh,
+> and I would drop the annex H stuff or move it to a separate AI that
+>can  later be killed quietly: Tuck was clearly smoking something when
+>he wrote  that part.
+
+I have mixed feelings on that.  I can't decide whether this is a brilliant idea
+(prevent dangling pointers without the costs of garbage collection) or
+yet-another coextension (a feature that only Tuck is smart enough to know how to
+use).
+
+Putting it in Annex H has some appeal for me.  Folks can ignore it.
+
+Also, at this point, I am primarily worried about complexity of implementation,
+rather than complexity of the language per se. And I think this stuff isn't hard
+to implement -- just some run-time library code, am I right?  (It's 10 times
+easier to write code to do X than to write code that generates code to do X. So
+run-time library work is easier than compiler work. As Steve Baird once said to
+me, it's easier to grab something with a pair of pliers than to grab the two
+handles of a pair of plyers with a pair of pair of pliers.)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, December 31, 2009  3:27 PM
+
+By the way, I've been meaning to say this for a while:
+
+I don't like the word "subpool".  I invented this term when I was working on
+SofCheck's CodePeer tool (nee' Inspector, nee' StatCheck).  I was thinking these
+pools carve up bigger pools, allocating little objects out of big chunks that
+are allocated from the bigger pool.  In other words, I was thinking about
+physical memory management.  It's wasn't a new idea -- lots of programs,
+including the AdaMagic compiler, do something like that.
+
+I think we should use a more mainstream term, such as "region".
+
+Tucker's subpool proposal, although somewhat based on my earlier work, is really
+more about lifetimes and dependencies and whatnot -- i.e. it's higher level than
+physical memory management.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, December 31, 2009  4:05 PM
+
+I would like to see some real user input on this feature.
+It sounds like a major implementation headache, and I am unsufficiently
+convinced that applications programmers would actually use this feature.
+
+I don't want any more leap seconds in the language :-)
+
+[I think he meant "subpools" by "this feature", but there is no context in his
+message; it could be anything in this AI. - Editor.]
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, December 31, 2009  4:06 PM
+
+> I think we should use a more mainstream term, such as "region".
+
+PL/1 uses area if I am remembering right?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, January 3, 2010  8:56 PM
+
+Several languages have adopted the "new T(...)" syntax for creating objects,
+including Java, C#, and C++.  In C++, if you are going to parameterize the
+actual allocation rather than the constructor, it is done by inserting the
+parameters in parentheses immediately after "new".  These are essentially seen
+as parameters to "new".  Hence new(alloc-params) T(...). I don't love the
+syntax, but I believe there is no reason to be arbitrarily different from
+existing practice, when adopting a capability that already existed in another
+language.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Monday, January 4, 2010  12:37 AM
+
+By that reasoning, I suggest that you support "= 0" as an alternative to "is
+abstract".
+
+I'll point out that this particular C++ feature is quite uncommon in practice,
+and that even experienced C++ programmers may not be familiar with it.  So I
+don't buy the "consistency with other languages" argument here, and I think that
+the internal consistency (and readability) of Ada carries more weight.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent