Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!usenet-fr.net!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!nx02.iad01.newshosting.com!newshosting.com!216.196.98.144.MISMATCH!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!spln!extra.newsguy.com!newsp.newsguy.com!news2 From: Michael Wojcik Newsgroups: comp.lang.java.programmer Subject: Re: Managed-Code Bloat Date: Sat, 11 Jun 2011 14:00:11 -0400 Organization: Micro Focus Lines: 56 Message-ID: References: <8486d40e-0cc1-40ec-93bc-41658d22edeb@r33g2000prh.googlegroups.com> NNTP-Posting-Host: pc2bb7b8c24f1c5a7d7f26add4948e73939b85b2200123096.newsdawg.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5212 Martin Gregorie wrote: > On Wed, 08 Jun 2011 11:48:22 -0400, Michael Wojcik wrote: > >> Martin Gregorie wrote: >>>> >>> Garbage collection and stack management are largely irrelevant for >>> COBOL - all data space is declared statically and the ways in which >>> PERFORM can be used more or less guarantees that its use will not >>> involve the stack. >> That hasn't been true, in general, since COBOL-85. While there certainly >> are still old COBOL applications with fixed-size memory requirements, a >> great many written over the past quarter-century make use of arbitrary >> subroutine call (ie, out-of-line perform and call) patterns, and a >> smaller number use reentrancy and/or threading. >> > OK, I'd agree about dynamically loaded subroutines, though those scarcely > need a GC since the allocation/deallocation points are well known, Agreed so far - I was more concerned with the "stack management" part of your statement than the "garbage collection" part. > but > are you saying that the content of WORKING-STORAGE can be dynamic now? I don't have a copy of the COBOL-85 standard handy, but since the mid-80s various COBOL implementations have provided extensions for dynamic memory allocation, which COBOL supports through USAGE POINTER, LINKAGE SECTION, and the SET statement. So Micro Focus COBOL has long had the CBL_ALLOC_MEM library call; IBM mainframe COBOL has had various environmental facilities like EXEC CICS SET ADDRESS, GETMAIN, etc; and so on. COBOL-2002 specifies the ALLOCATE and FREE statements (which I don't think were in COBOL-85), standardizing this kind of explicit memory allocation and release. Those are *not* garbage-collected allocations, but they pointed to the desirability of garbage collection for modern COBOL; and that's why the first proprietary OO COBOL dialects were garbage-collected, and that remains true with modern OO COBOL, including COBOL-2002 (see ISO/IEC 1989:2002 9.3.14.2) and Micro Focus COBOL for .NET and JVM. >> And there have been garbage-collected COBOLs at least since the first OO >> COBOLs appeared in the 1990s. >> > OK - but I've never used or seen those flavours. Yes, they're still relatively rarely used, compared to traditional COBOL. I was just noting that the state of the art in the COBOL standard and implementations has moved on since the old static-allocation-only days. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University