From JLS@liverpool.ac.uk Wed Aug 19 14:36:42 1992 Received: from vm.uni-c.dk by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA08828; Wed, 19 Aug 92 14:36:42 +0200 Message-Id: <9208191236.AA08828@dkuug.dk> Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R2) with BSMTP id 1171; Wed, 19 Aug 92 14:37:23 DNT Received: from UKACRL.BITNET by vm.uni-c.dk (Mailer R2.07) with BSMTP id 6203; Wed, 19 Aug 92 14:37:22 DNT Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 2016; Wed, 19 Aug 92 13:36:24 BST Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 3586; Wed, 19 Aug 92 13:36:23 BST Via: UK.AC.LIV.IBM; 19 AUG 92 13:36:20 BST Received: from UK.AC.LIVERPOOL by MAILER(4.4.t); 19 Aug 1992 13:33:52 BST Date: Wed, 19 Aug 92 12:54:46 BST From: Lawrie Schonfelder Subject: Re: (SC22WG5.156) Defect Report To: bill@amber.ssd.csd.harris.com Cc: SC22/WG5 members In-Reply-To: Your message of Tue, 18 Aug 92 09:18:12 -0400 X-Charset: ASCII X-Char-Esc: 29 On Tue, 18 Aug 92 09:18:12 -0400 bill@com.harris.csd.ssd.amber said: >> Date: Tue, 18 Aug 92 12:55:37 BST >> From: Lawrie Schonfelder > >> If I know the pointer is there I can but If I dont because it is a component >> of a type whose structure is PRIVATE I dont. > >If I understand you correctly, then, the problem is that Fortran 90 >invented PRIVATE types but neglected to provide constructors and >destructors so they could be properly initialized. Is that right? In part yes. Only part of the job was done. Unfortunately every attempt at completeing the job was blocked, in fact during the latter hectic days a number of changes were introduced that made the problem worse. We have implicitly defined constructors, but no user definable overload for these. We rightly allow user definable override for assignment but do not allow this to be used for initialisation. > >> The inefficiency of having to set disassociated each >> pointer as it is created is spurious. In any system that does full garbage >> collection, which any high quality implementation must do. It must distinguish >> between not yet associated and genuinely dangling or it would be impossible >> to produce safe garbage collection. > >First of all, this comment is not true. Most garbage collection systems >for languages like C, Ada, Pascal, etc. do conservative garbage collection. >That means that if a memory location contains something that looks like a >pointer into the heap, then the pointed-to location is considered "used" >and therefore not garbage to be collected. > >Second, it would be a colossal mistake to *mandate* garbage collection in >all Fortran implementations. We already have. But not all programs will require it. Any program that makes heavy use of pointers and dynamic memory allocation, particularly with the present initial status fault, will have to leak memory like flywire jug. Such programs will require garbage collection or will quickly run into system limitations. >I'm not saying that garbage collection is >universally bad -- it certainly has lots of useful applications. But it >does have a couple of very bad characteristics. One of these is that the >garbage collector tends to touch all of memory fairly often. That's very >bad for virtual memory systems if the application gets very big. Second, >garbage collection introduces extreme unpredictability in timing, which is >anathema in the real-time industry. (How would you like your neighborhood >chemical plant to explode because the monitoring system didn't respond to >an alert in the proper amount of time?) Real-time programs had better not employ techniques and facilities that also require garbage collection. I am well aware of this problem. All that you are saying is that different application areas will need to use different facilities and different aspects of implementations. I am concerned that one such areas needs should not wipe out another which it currently does. > >> The cost of setting any not-yet-associated flag will be pretty much the >> same as setting disassociated. If you dont like initially disassociated I >> would settle for an additional status of not-yet-associated and some way >> of detecting this fact in the Fortran program. If I cannot detect not-yet associated and initialisation is not enforcable as a default (a user requirement that may or may not be met is not adequate) the producer of general purpose application facilities has to program defensively, just as the writer of a compiler must do when attempting to optimise code. This means I have to assume nothing about the initial status of any pointers and hence I am forced to always nullify never deallocate, with all the costs that this entails. I contend these costs are going to be high vastly higher than any associated with setting a defined default initial status for all pointers. How often are large arrays of types containing pointer components going to be allocated ( the only place where there can be any significant cost) and when they are what relative overhead is the initialisation likely to be. I would have thought tiny compared to what else is likely to be done with such objects. >But, as you just pointed out, the two are the same cost. Since I object to >the first one on the basis of its cost, I'm unlikely to accept your >alternative. > >Bill Leonard >Harris Computer Systems Division >2101 W. Cypress Creek Road >Fort Lauderdale, FL 33309 >bill@ssd.csd.harris.com >--------------------------------------------------------------------------- > Q: How many lawyer jokes are there? > A: Only three. The rest are true stories. >---------------------------------------------------------------------------