×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 06-Apr-2012 12:11 , Nathan Andelin wrote:
From: Alan Campin
The same thing in a C program needs 270 bytes.
What happens if you code the following in main()
static int x = 0;
I haven't tried it, but my guess would be that the static
storage used by the C program would also be around 4K. If I
understand correctly, storage under IBM i is allocated in 4K
minimum blocks using system APIs. Wouldn't that be what the
compiler would do?
I do not believe that would be the case.
Being associated with the process, thus being storage outside of any
"object", the size for the program static storage is not dictated by any
[object] minimum page size nor any other similar dictum. Thus the
static storage size used to support all of the declared static storage
in a program can be exactly the number of bytes declared as static;
storage that is acquired by the process dynamically [irrespective the
/static/ moniker], according to the defined "static storage size"
requirement of the compiled program object. The noted 270 byte static
storage size for the C program storage is more likely to be accommodated
in the actual run-time on a 16-byte boundary rather than a 4K boundary,
thus presumably taking 272 bytes of dynamically acquired process static
storage. IIRC, the output from DMPJOB PGM(named) shows the actual
static storage [for a previously invoked program] fairly clearly and
conspicuously.
In a later message in this thread, what I suggest below is apparently
already understood; best I can infer from the comments made about "the
difference between 'static' and 'heap' storage".
http://archive.midrange.com/rpg400-l/201204/msg00092.html
However "heap" storage might just as well have been called "memory",
because the means to acquire dynamic storage that is not directly
associated with the implementation of the process, need not be limited
to acquisition from the heap. Much of the DB2 for example, had long
relied [presumably still] on non-heap miscellaneous temporary storage
[spaces]. For the process, the two types of [OPM] storage are
"Automatic storage size" and "Static storage size"; i.e. "program
automatic storage area" PASA and "program static storage area" PSSA,
both of which are allocated within the process.
The compiler would prepare the object for any amount of storage that
is required to accomplish what the program needs to do at run-time,
according to what is necessary to accommodate all of the [referenced]
variable declarations made by the program. However because the compiled
objects do not physically "contain" the storage that will be used for
the static variables, the compiler effectively does little more than
store a number, the "Static storage size" [per DSPPGM], in order that
the LIC\AI "Activation Invocation" feature knows how much [the actual
/size/ of the] storage must be acquired within the "process storage"
when the program is invoked.
The [process] Static storage, much like the [process] automatic
storage, is process storage that is allocated dynamically within the
process, effectively for [associated with] the stack frames. The
difference between them is effectively that program static storage is
allocated and initialized only on the first invocation of the program
within a process\job, whereas the automatic storage is allocated and
[optionally] initialized on every invocation of the program within each
thread of a process.
Regards, Chuck
As an Amazon Associate we earn from qualifying purchases.