next up previous contents index
Next: MZREPL - connect Up: Memory management Previous: MZLIFT / MZBOOK

MZPUSH - alter the size of a bank

MZPUSH (increasing) may cause garbage collection.

To increase or decrease the size of a bank, one may

CALL MZPUSH (IXDIV,*!L*,INCNL,INCND,chOPT)

with

       IXDIV  index of the division; zero [or IXSTOR] allowed,
              in which case MZPUSH will find the division

        *!L*  address of the bank to be pushed,
              on return L contains the new address of the bank
              (cannot be a link in a bank !)

       INCNL  number of additional links,
              zero for no change, negative for decrease.
              Additional links will be given type 'reference',
              unless the original bank has only structural links.

       INCND  number of additional data words,
              zero for no change, negative for decrease.

       chOPT  character string of options:

                 default: any link may point to the bank at L,

              R  but not into the abandoned bank region
                        (in case of bank reduction)

              I  isolated: only the inherent structural links
                           point to this bank
For 'isolated' the user is sure that no link other than the supporting structural link, and the link passed in the parameter L, and the reverse links in the first level dependents, point to this bank.

The I/O descriptor of the old bank must also be valid for the new bank; if this would not be the case one should use MZREPL instead of MZPUSH.

New link words and new data words acquired by the bank are cleared to zero.

Except for special cases, increasing the size of a bank is an expensive operation, and should be avoided. The correct solutions to the problems of indefinite number of objects or of indefinite size are either the use of a linear structure or the lifting of a bank of maximum size, which is reduced to the final size once the contents are complete.

The increase of a bank is handled in general as follows: a new bank is lifted with the new dimensions, the contents of the original bank are copied over, and the old bank is marked as dropped. Any link pointing to the original bank must be re-routed to the replacement bank by MZPUSH. In full generality this can only be done by a relocation pass over all memory (ie. all link areas and all divisions pointing to the division in which the bank resides.)

The expensive part in this operation is the relocation pass, and this can be saved under special circumstances:

a) Increasing the data part of the last bank in a forward division, or the link part in a reverse division, can be done in situ without the lifting of a new bank. Hence any link pointing to the bank remains valid. (However note: this is not a good reason for creating an extra division, because the lifting of a maximum size bank is a better solution.)

b) If there are no links pointing to the bank (except the standard structural support links) there is no point to scan all links, because the relocation pass would have no effect. However, ZEBRA could not detect this situation without actually performing the relocation pass, but the user may know the situation a priori, in which case he can signal it to MZPUSH with the I option.

Reducing the size of a bank is less onerous (if the R option is given). The parameters of the original bank are adjusted to the new dimension in situ and the abandoned memory is marked as dead. Links which point into the abandoned region, if any, can only be reference links and must be reset to zero. To have links pointing into a bank, rather than to the status-word, is relatively rare. Again, the relocation pass can be saved, and for reducing a bank this is the normal situation, if the user knows the situation a priori and signals it to MZPUSH with the R option (or I which is stronger).

MZPUSH prints a monitor log message at level 2, but if the operation involves a relocation pass a log message will be given at level 1.

MZPUSH accumulates statistics of the number of times that an expensive operation was performed; this is printed by MZEND.



next up previous contents index
Next: MZREPL - connect Up: Memory management Previous: MZLIFT / MZBOOK


Janne Saarela
Mon May 15 08:34:47 METDST 1995