Browse Prior Art Database

High Performance Allocation of Automatic Storage for Multi-CSECT Modules

IP.com Disclosure Number: IPCOM000112615D
Original Publication Date: 1994-Jun-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 2 page(s) / 129K

Publishing Venue

IBM

Related People

Havercan, PE: AUTHOR

Abstract

Modules compiled with a compiler may require automatic storage to be allocated before module execution can begin. Without special action the compiler may issue an Operating System GETMAIN macro to acquire this storage. The GETMAIN service consumes a large number of instructions relative to the instructions executed within the compiled module. Problems solved by this disclosure are to ensure that the automatic storage is allocated without frequent use of the GETMAIN service, to ensure that just the required amount of storage is allocated and to permit the storage allocated to be shared between multiple independently compiled modules that make up the using load module.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 44% of the total text.

High Performance Allocation of Automatic Storage for Multi-CSECT
Modules

      Modules compiled with a compiler may require automatic storage
to be allocated before module execution can begin.  Without special
action the compiler may issue an Operating System GETMAIN macro to
acquire this storage.  The GETMAIN service consumes a large number of
instructions relative to the instructions executed within the
compiled module.  Problems solved by this disclosure are to ensure
that the automatic storage is allocated without frequent use of the
GETMAIN service, to ensure that just the required amount of storage
is allocated and to permit the storage allocated to be shared between
multiple independently compiled modules that make up the using load
module.  Because the amount of storage to be acquired is determined
across many shared, but independently compiled modules, the size of
storage required is automatically calculated by the Linkage Editor.
Although optimized for single thread use of pre-allocated storage, it
does not preclude concurrent users from executing the same code,
though at degraded performance.

      The use of external dummy sections, Q-type address constants,
and the CXD instruction are all documented in OS/VS-DOS/VSE-VM/370
Assembler Language, GC33-4010.

      If a compiler allows customization of the automatic storage
allocation mechanism through the use of "STACK" macros then the
technique may be used.  "STACK" macros are user-supplied Assembler
language macros invoked instead of the Operating System GETMAIN and
FREEMAIN macros.  The solution to the performance problem is the
provision of versions of the STACK macros.  Two macros need to be
provided:  a GET-SPACE macro to acquire the automatic storage, and a
FREE-SPACE macro to release the automatic storage.  The use of STACK
macros themselves is not new.  Novelty is the method by which the
amount of storage to be used is determined.  To reduce the execution
time within the GET-SPACE macro, the automatic storage is acquired
upon the first invocation, and then retained for subsequent
invocations.  The technique requires the address of the retained
storage to be preserved in an easily-addressable fullword within a
global control block that is external to the compiled module.  In
what follows, that fullword will be referred to as the SAVEAREA.  The
approach taken within the GET-SPACE macro is that, if the SAVEAREA is
zero, then storage must truly be acquired with a GETMAIN.  If the
SAVEAREA is non-zero, the storage has already been acquired so it can
be reused.  The address of the acquired storage is only saved in the
SAVEAREA by the FREE-SPACE macro.  That an address is stored in the
SAVEAREA is a signal to GET-SPACE that the storage is no longer in
use, so it can be reused.

      If the pre-allocated storage is reused by GET-SPACE, the
SAVEAREA is set to zero to indicate that no pre-allocated storage is
available.  So that there is no possibi...