Changes in load module size between V4 and V6

The most important reason for executable code growth between V4 and V6 is an advanced optimization in V6, which was introduced in V5, to inline some out-of-line PERFORM statements to their calling site. This inlining has a number of advantages for program performance. First, it avoids the overhead of dispatching and returning from the out-of-line perform. Second, it exposes the statements being performed to further optimization in the context of the surrounding statements. This latter reason often allows the optimizer, even at OPT(1), to exploit synergies and to eliminate redundancies in order to improve performance. Tuning has been done since V5.1 to reduce the number of PERFORMs that are inlined in cases where a performance increase is unlikely.

In V6, the INLINE and NOINLINE options are introduced to control whether the inlining of procedures (paragraphs or sections) referenced by PERFORM statements in the source program. For details, please view INLINE in the Enterprise COBOL for z/OS® Programming Guide.

There are other reasons as well why the executable size may be larger in some cases compared to V4:
  • Use of higher ARCH instructions that are usually 6 bytes versus 4 bytes for many lower arch instructions. For example:
    • Using more than one ARCH(8) move immediate instruction instead of one in memory move
    • Exploiting Decimal Floating Point for packed/zoned decimal arithmetic
  • Various V6 optimizations over and above V4 results in more generated code but shorter path length and better performance. For example:
    • More advanced INSPECT inlining
    • Conditionally inlining some complex conversions
    • Conditionally correcting decimal precision for binary data
    • Speeding up MOVEs to numeric-edited and alpha-numeric-edited data items
  • V4 used "base locator" pointers accessed by 4 byte load, but in V6, fewer base locators are used, but 6 byte long displacement instructions are used instead
  • V6 has a higher unroll threshold than V4 when deciding to use multiple MVCs for large copies to avoid a more expensive MVCL instruction