[comp.lang.fortran] Gigantic character variables

hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (03/25/89)

In article <587@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl 
Dept of Biophysics  SM), I muckraked fortran language
implementors for converting the standardization process into
a demolition derby and the standards organizations of egregious
neglect in the enforcement of the standard.  The X3.9-1978
standard was pregnant with many potentially useful feature. One
of them was the CHARACTER typing statement; both character
arrays and character variables were allowed.  While the
implementors proceeded to render the character variable unserviceable
for use in portable programs, the standards committee with remarkable
indifference entered hibernation.  History seems about ready to
repeat itself.

I also posted a short validation program and reported that only
AT&T, showing a kinder-gentler attitude toward standardization,
allowed a character variable to be 750000 bytes long.  I
received an email message from Daniel Levy, att!ttbcad!levy,
suggesting that the string variable be put into COMMON:

*     PROGRAM GIGANTIC_STRING
      PARAMETER (K=7280900)
      COMMON /GENE/ AND
        CHARACTER AND(K)*1
        CHARACTER*(K) DNA
        EQUIVALENCE (DNA,AND)
      DNA(K-23:K) = 'An exercise in futility!'
      PRINT *,K,(AND(J+K-24),J=1,24)
      END

For (K .LE. 7280900), the AT&T XLA+ fortran compiler compiled the
program and its execution on our AT&T 3B2 worked!  That is not bad
for a machine with only 4 M bytes of RAM memory.  Daniel also said
"...modern paging operating systems should make the issue of gigantic
arrays and small core practically moot. ...  You should be able to have
an uninitialized array almost as big as the maximum process size on
the 3B2 (16 meg)."

When (K .GT. 7280900 Mbytes), the following run time diagnostics are
printed and the executions are killed:
  XLA+ NOTICE:  growreg -- Insufficient memory to allocate 3621 pages -
         system call failed.      /* For K=7284000 */
  XLA+ NOTICE:  growreg -- Insufficient memory to allocate 8145 pages -
         system call failed.      /* For K=16665045 */
  XLA+  a.out too big         /* For K=16670045 and K=100000000 */
Hmmm.. The diagnostics suggest that I may be able to tweak the
system into giving me another 8 M bytes.  Does anyone know how
I might do it?  

Let me apologize to AT&T for selling them 7 Mbytes short.  I
must say they do seem to know how to do it right.  I think I
should also say that I am not connected with AT&T.

----------------------------------------------------------------------
Albert Hybl, PhD.              Office UUCP: uunet!mimsy!mbph!hybl
Department of Biophysics       Home   UUCP: uunet!mimsy!mbph!hybl!ah
University of Maryland                CoSy: ahybl
School of Medicine
Baltimore, MD  21201                 Phone: (301) 328-7940 (Office)
----------------------------------------------------------------------

dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (03/30/89)

In article <589@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl  Dept of Biophysics  SM) writes:
     For (K .LE. 7280900), the AT&T XLA+ fortran compiler compiled the
     program and its execution on our AT&T 3B2 worked!  That is not bad
     for a machine with only 4 M bytes of RAM memory.  Daniel also said
     "...modern paging operating systems should make the issue of gigantic
     arrays and small core practically moot. ...  You should be able to have
     an uninitialized array almost as big as the maximum process size on
     the 3B2 (16 meg)."
     
     When (K .GT. 7280900 Mbytes), the following run time diagnostics are
     printed and the executions are killed:
       XLA+ NOTICE:  growreg -- Insufficient memory to allocate 3621 pages -
              system call failed.      /* For K=7284000 */
       XLA+ NOTICE:  growreg -- Insufficient memory to allocate 8145 pages -
              system call failed.      /* For K=16665045 */
       XLA+  a.out too big         /* For K=16670045 and K=100000000 */
     Hmmm.. The diagnostics suggest that I may be able to tweak the
     system into giving me another 8 M bytes.  Does anyone know how
     I might do it?  
     
The kernel will not run a process unless there is enough space on
the swapping disk to accomodate ithe entire memory of the
process.  Your swapping space is insuffiecient to hold the whole
process as well as all the other processes who are running at the
same time.

One will have to increase the swap space to at least 16 megs (use
/etc/swap to add more space or repartition the swap disk).  In
addition the maximum memory a process is allowed is limited by
two different things:  First there is a hard limit imposed by the
fact that the user's address space is limited to only part of the
32 bit address space: the bottom half of the address space is
reserved for kernel use.  Then a large section is reserved for
the users ublock and stack.  The actual space available for a
user starts at 0x80800000.  The first part is used for the
program text, then comes data, bss and then the heap.

The second limit is there is a tuneable parameter in the kernel
that limits the maximum size of a process.  It is set in most
systems to give 16 megs of user accessible memory.  It can be
changed -- its name is MAXUMEM and is set to 8192.

The growreg messages are from the kernel and are printed on the
console and are explaining that there is insufficient swap
available to allow this process to run. [Similar messages occur
when a sbrk (or mallor) are given and there isn't room].

As I said above, increase your available swap.  You may also have
to increase MAXUMEM and rebuild and reboot.
-- 
=Dennis L. Mumaugh
 Lisle, IL  ...!{att,lll-crg,attunix}!cuuxb!dlm  OR dlm@cuuxb.att.com