Oppolzer - Informatik / Blog

There was a comment from Mr J.G. on IBM Main, too, but I prefer to post
here, although it is more a PL/1 topic. Maybe we should discuss it further on
the PL/1 list.

In my opinion, the generated code cannot be reentrant, if the programmer decides
to modify STATIC variables, and if the compiler option RENT is not set. In this
case, the STATIC variables are placed in a STATIC CSECT, which is part of the
load module, and so the load module is modified during execution, and so the
module can never be reentrant. So it is in the responsibility of the programmer
to make his or her module reentrant or not. This is what we teach our
programmers: use AUTO (which is the DEFAULT at our site) for working storage and
STATIC only for constant values.

If the programmers follow these guidelines, the modules are naturally reentrant,
and the linkage editor option RENT may be set (which has positive effects on
performance in some environments).

If, in this case, you specify the RENT compile option, the following happens:

all STATIC variables are placed in the WSA. The WSA is dynamically allocated on
the enclave level (during start of the enclave). If the STATIC variable have
INIT values, the INITs have to be done by dynamic initializations at run time.
That is, you have three drawbacks:

- additional space for the init patterns in the load module (the space in the
WSA is the same as the space in the STATIC CSECT in the other case)

- larger load module due to initialization logic

- CPU consumption due to initialization, although only on enclave start

Think of large static arrays with INIT. This may be costly.

And it does NO GOOD AT ALL.

That is why I vote against the RENT compiler option.

The only reason for the compiler option RENT in PL/1 is IMHO: because C++ needs
it (and it was inherited from C++ in the first place). In C++ it is allowed to
initialize static variables with a function call, so you cannot restrict it to
compile time values. This may be comfortable for the programmer, but it's a big
problem for the run time system. And I don't like it, because it leads to
performance problems, IMO.

C (without ++), BTW, does not allow these kind of initialization, and therefore
works perfectly without RENT (that is, NORENT), and that's what we do all the
time. No problem with C, only C++.

I don't like it, if PL/1 runtime paradigms are contaminated by C++ ones.

Kind regards

Bernd



S.C. schrieb:
> Bernd Oppolzer wrote:
>> Similar to C, all STATIC variables are placed in the WSA, to make the
>> module "artificially" reentrant, even if the module changes its static
>> variables.
>>
>> At our site, this idea was esspecially ill-fated, because we told our
>> developers for some 20 years to make all the modules "naturally" reentrant,
>> so why should we compile with the RENT option? But it took us - a colleague
>> of mine and myself - 3 years (from 2003 to 2006) to convince the compiler group
>> that the compiler option RENT does no good.
>>
>> But in other - larger - branches of the same company, the RENT compile
>> option is still alive.
>>
>> Kind regards
>>
>> Bernd
>>
>>
>
> One of the PL/I compiler developers once told me that the
> generated code will always be reentrant: that's a design
> goal. (The PL/I and C compilers use the same code generation
> engine, I'm told, so the point should still be correct for
> C.)
>
> So I would say the RENT compile option is unnecessary, not
> that it "does no good"; that makes it sound like it actually
> does harm. So why bother arguing about including RENT or not
> if it makes no difference?
>
>
> --
>
> Kind regards,
>
> S.C.
>