Oppolzer - Informatik / Blog

On Sun, Jun 6, 2010 at 1:25 AM, Bernd Oppolzer
<bernd.oppolzer@t-online.de> wrote:
> 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.

<snip>

> 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.

We ran into this issue at shop also and there is an additional reason that
naturally reentrant is preferred over constructed reentrancy for C/C++. No PL/1.

Our application (batch) has dozens of TCBs which perform specialized tasks. Data
is passed between the TCBs on queues. When each TCB is attached, the parm points
to a control block in the root TCB. Anchored off of this control block are
various vector tables which contain program addresses and other various bits of
data. The programs are loaded (and the addresses put in the vector table) by the
initialization TCB. The programs can then be used by any of the other TCB as
required.

Each TCB creates its own CEEPIPI enclave.

If the application did not use natural reentrant programs, we would have to load
the programs under each TCB instead of just the initialization TCB. This would
have significant increased application complexity.

<snip>

> Kind regards
>
> Bernd
>
>
>