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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Received: by 2002:a6b:bb42:: with SMTP id l63-v6mr1131916iof.101.1528984106265; Thu, 14 Jun 2018 06:48:26 -0700 (PDT) X-Received: by 2002:a9d:70c2:: with SMTP id w2-v6mr155223otj.2.1528984106164; Thu, 14 Jun 2018 06:48:26 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!nntp.giganews.com!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!85.12.16.68.MISMATCH!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.am4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!u78-v6no812710itb.0!news-out.google.com!z3-v6ni1059iti.0!nntp.google.com!d7-v6no829258itj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 14 Jun 2018 06:48:26 -0700 (PDT) Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=137.103.119.68; posting-account=ShYTIAoAAABytvcS76ZrG9GdaV-nXYKy NNTP-Posting-Host: 137.103.119.68 User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Comprehending subpools From: sbelmont700@gmail.com Injection-Date: Thu, 14 Jun 2018 13:48:26 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 7025 X-Received-Body-CRC: 2880577406 Xref: reader02.eternal-september.org comp.lang.ada:53100 Date: 2018-06-14T06:48:26-07:00 List-Id: Hi, I've been trying for what I guess is six years now to figure out subpools, = and I just can't seem to make heads or tails of it. Yes, I understand it i= nasmuch as it means you can deallocate multiple objects at once with proper= finalization, but it seems like a hell of a lot of work went into it, with= multiple AI's, hundreds of comments, and what has to be thousands of man-h= ours for a feature that seems niche, at best. The AI's are filled with big= talk and grand plans (the phrase "portable garbage collecting pool" was ut= tered), and even the "Controlled" pragma was marked as being supplanted by = subpools, but what made it into the language seems, well, not much better t= han what was there already. But it wouldn't be the first Ada feature that = was too complex for programmers to understand, so please point out where I = have gone off the rails. The rationale says "this is far safer and often cheaper than trying to asso= ciate lifetimes with individual objects". But is it really?=20 Deallocating subpools is still just as unchecked as deallocating an individ= ual objects, and it's not like you get partial credit for dangling referenc= es. Deallocating a subpool with a reference into it still hanging around i= s just as unsafe as regular Unchecked_Deallocation, so you still have the s= ame old problem of either limiting the scope, or reference counting everyth= ing. And practically, if you are going to reference count it, it's going t= o be some generic, reusable package that either works right for everything = or nothing at all, which is exactly as safe/unsafe as it was before. Moreover, reference counting in a world of subpools is even harder, because= not only do you have to worry about the objects in the subpool, but the su= bpool handle itself. So it becomes a *more* complex task of ensuring that = a) all the references into the subpool are gone and B) all references to th= e subpool itself are gone. The reference counted values would need some me= chanism to know which subpool they came from, which probably means the subp= ool handle, which now also has to be reference counted, so you have shared = pointers inside of shared pointers, which i would classify as "at best equa= lly complex and error prone" instead of "far safer". You could argue you m= ight save some bytes by only having a single total reference count instead = of many, but that is probably offset by needing to save the subpool referen= ce anyway. And of course this means reference counted subpool values would= be different than normal reference counted values, which means a THIRD typ= e of incompatible pointer running around; i.e. you still can't have a set o= f references that can hold 'regular' (accessibility-checked) access values,= 'standard' reference counted values, and subpool counted values. Alright, so maybe this is intended for the case where you can control the e= ntire scope, and not have to worry about passing them around. But in those= cases, can't you just declare a new access type and use 'Storage_Size (or = a normal storage pool) to give you exactly that? The only reason to use a = subpool is when the type has to be declared at a higher scope, which is pre= sumably so you can pass that type around (and save it off somewhere), which= demands some sort of reference counting. So then perhaps it's "often cheaper"? It will certainly be faster to deall= ocate a big chunk than a bunch of little chunks, but all premature optimiza= tion platitudes aside, I can honestly not think of a time when the speed of= deallocations concerned me in the least, as either programmer or user. No= rmally this happens when the program (or significant portion of it) is over= , at which point who cares how long some thread runs in the background clea= ning up storage? Even the given example of a retail shopping web site seem= s forced; who worries about how long a web server takes to deallocate old s= hopping cart data after the user has closed his browser? If anything that = example demonstrates the need for some form of automated garbage collection= , not optimizing the manual method. Moreover, even in a supposed use-case where speed DOES matter, the whole po= int of this change was to do it in a way that allows for finalization of th= e objects; otherwise the pre-existing Mark/Release pool was sufficient. Bu= t if you need a subpool because all these objects are going to have complex= finalization, isn't that almost certainly going to be the bottleneck? The= runtime still has to walk through the list of objects, one-by-one, and run= their big, slow, complex Finalize procedures. So the idea that you can ju= st 'adjust a pointer' and be done with it really doesn't hold water either. So at the end of the day, i can't see how much of any of this is better tha= n what was already there, and certainly not to the extent it was worth the = apparently enormous amount of time spent, especially when there are other t= hings begging for improvement. It seems like it would have been much more = efficient to just make the mark/release pool a standard library package ins= tead of an example, and add a rule that saying that the implementation need= s to finalize the objects within. I have to assume I just haven't had that "a-ha!" moment that readjusts my o= ld way of thinking, so does someone actually have a real, serious, concrete= example of something using subpools that warrants the time and expense tha= t this took? I'm all for revising the memory management facilities in Ada = (I long for the day when you can use raw access values from a reference-cou= nting pool, a mark/sweep pool, and those generated from 'Access interchange= ably), but this just doesn't seem to be it. -sb =20