El enfoque interactivo

This optimisation functions well, but since large numbers of temporary fvals are created, a scheme is needed to clear and remove fvals from fval info once they are

a b c d

...

@042b0190 042b0190 f1 f2 f3 @042b1194 @042b1198 @042b119c x

/

+

Memory locations Interesting values Floating point operations Interesting new values 042b0194 042b0198 042b019c

Fig. 6.4: Tags for a simple expression

fval Instruction address Argument 1 Argument 2

f1 0x08048556 From 0x042b0190 From 0x042b0194

f2 0x0804855a f1 From 0x042b0198

f3 0x0804855e f2 From 0x042b019c

Table 6.1: fval info table for a simple expression

stored to memory and no longer used. To do this, the following properties of fvals are observed:

1. fvals are similar toIRtemporaries in that unless they are explicitly stored some- where, they will cease to exist once DART leaves a basic block. Also like tempo- raries, fvals can be written into either registers (in the guest state), or memory locations.

2. An fval can potentially be used for a store to a marked memory location if there is a copy of it anywhere in memory or in the register file. Information about it must be kept ‘alive’ as long as any copies of it exist, since if a store does occur, DART will need to discover which arguments it was derived from as a part of the recursive backtracking.

3. An fval may have no copies of it either in the register file or in memory, but DART may still need to keep a copy of the fval if a second fval derived from this fval is still alive. This occurs when an fval is used as one of the arguments to a floating point operation.

These constraints can be met by adding a reference count field to each fval info entry. If the reference count is non-zero, the fval is ‘alive’. It is incremented for every reference to it that exists, and decremented when those references are removed, and once it is decremented to zero the fval is ‘dead’ and the entry in fval info can be wiped. An entry is wiped by setting the reference count and flags to zero, and the argument fields to the empty value.

To honour property 2, every time the fval is written to unmarked memory or registers (i.e., a copy is made of it and its tag), the reference count is incremented. Each time the fval is overwritten by something else (i.e., a copy is destroyed), the reference count is decremented.

To honour property 3, every time an fval is created (as the result of a floating point operation), if either of the arguments is an fval, their reference counts are incremented — the fval must keep its ‘parents’ alive for as long as the fval itself lives. If an fval’s reference count is decremented to zero, it is first wiped and then the reference counts of its parents are decremented also — after wiping an fval ‘lets go of’ any references to its parents. This decrementing may in turn reduce the parents’ reference counts to zero in which case they too must wipe themselves and decrement the reference counts of their parents, and so on recursively.

Once this reference counting scheme is in place, DART can periodically compact the fval info structure by scanning the entire fval info table and deallocating the secondary maps that contain nothing but wiped entries in the same way as described inSec. 5.6.2.

This description might suggest that there is race condition at the point where a new fval is created. When an fval is created, its reference count is zero (but one or both of its arguments are non empty). Since there is an interval between the fval’s creation and the point where its reference count is incremented from zero when it is used as an argument to create another fval or stored to memory/a register, it would appear a compaction at this point would remove the value. However, the compaction is not where the garbage collection is really performed. The garbage collection occurs when the value is wiped. The compaction merely reduces the redundant storage by removing unneeded all-empty secondary maps. Since a newly created fval will have at least one non-empty field, the secondary containing it will not be removed. This does bring up the possibility of an fval being created but never stored or used to create another fval. Such an fval would never be removed since there would be no references to it, and nothing to decrement its reference count. In practice though, Valgrind’sIRgenerator will not produce theseµOp sequences, and even if

it or DART’s instrumentation did, they would be optimised out by anIRdead code elimination pass before the basic blocks are compiled.

In document El clima organizacional y el comportamiento estratégico en el desempeño del sector Hotelero en Arequipa (página 58-63)