Path: utzoo!attcan!uunet!mcsun!cernvax!achille
From: achille@cernvax.UUCP (achille petrilli)
Newsgroups: comp.sys.apollo
Subject: Re:  Mentor Graphics Mspice.020 server
Message-ID: <1236@cernvax.UUCP>
Date: 7 Feb 90 12:51:16 GMT
References: <9002061400.AA03716@umix.cc.umich.edu> <3322@paperboy.OSF.ORG>
Organization: CERN, European Laboratory for Particle Physics
Lines: 47

In article <3322@paperboy.OSF.ORG> lwa@osf.org (Larry Allen) writes:
>To be fair (but then, who ever said the world was
>fair? :^) and in defense of SR10, the behavior of
>requiring backing storage space for all allocated
>virtual memory is not only there for JLRUness, as
>Dave implies.  The fact is, Apollo received a fair
>number of complaints from customers, especially
>system vendors, who found it difficult to write
>applications that would be robust in the face of
>running out of disk space.  The problem is that the

I really couldn't resist to answer to that. What we feel
here, as a big Fortran shop, is that Apollo just didn't think
of what they were doing.
Why ? Well, until FTN90 gets approved and some implementations
of it become available and people start converting (I mean,
really using the new features of F90), there is NO standard
way of getting rid of the big common blocks that should be
dimensioned for the worst case ! So, that's why I believe
Apollo completely overlooked (some of) its customers wishes/needs.
Of course, as our FTN programs run, and must run, on many
different OSs, some of 'em hopelessly obsolete, we cannot
use system dependent dynamic memory allocation.
I do believe that this change has done a lot of harm to many
people.

On the C side, things are much better. Traditionally dynamic
memory allocation has been widely used in C programs. So
I guess this is not a big problem and, as you state, the
JLRU behaviour is actually better than the Aegis one.

I think the real problem is that the JLRU behaviour has "cured"
two distinct, and vaguely related problems: 
1) dynamic memory allocation (where I fully agree with JLRU),
2) static memory allocation.

1) is fine under sr10. But 2), I'd prefer to get an option to be
able to define how to treat it. 
Even if such an option would be available at boot time (say,
as an environment variable that is only effective if set 
while running /etc/rc), it'd be better than today's situation.

Also, your idea of a compile time stamp to indicate the preferred 
behaviour is a good one, but it may be a little to complicated.

Cheers,
	Achille Petrilli