4. Release Management

Release is the most complex mechanism implemented in JEVEUX. It is easy to imagine that when you manage a finite memory space, there comes a time when it is no longer possible to find space. It is then necessary to cause unloads to disk or to recover the space of areas that have become useless. JEVEUX takes care of these mechanisms, provided, of course, that the programmer has indicated the objects concerned; it is necessary to take certain precautions before freeing an object, as several program units can simultaneously use a memory address. The release strategy uses, on the one hand, a mechanism internal to the memory manager that we are going to describe and, on the other hand, to programming rules that are the subject of the document [D2.06.99] « New strategy for freeing objects JEVEUX ».

The release of a value segment is materialized by positioning the state at the value X instead of the value U. There is no other immediate effect; it is only during a subsequent search for a position in memory that the content of the value segments will be effectively processed.

The storage of a JEVEUX object is accompanied by the assignment of a system attribute: the brand. This attribute, of integer type, takes the value of a counter that is incremented with each call to routine JEMARQ and decremented with each call to routine JEDEMA. It is possible to get current brand value by calling the JEVEMA routine.

Current brands therefore have a strictly positive value. The values -1, -2, and -3 are used to handle the following exceptions.

The value -1 is used to keep at all times (throughout the execution of an Aster command) certain objects that will be released by a specific call. This mark is used when calling routine JEVEUT.

The value -2 is used by JEVEUX to temporarily bring back certain objects that will be released as soon as the action is complete (storage of collection system objects,…).

The value -3 is used to keep at all times (throughout the execution of Code_Aster) the objects used by the Supervisor.

The -3 brand can replace any existing brand, the -1 brand can replace an existing (positive) brand. The system object containing the list of the addresses of the value segments must then be modified. The -3 mark is used when calling routine JEVEUS.

A hierarchy of value segments associated with the objects is thus constructed. Each call to the JEDEMA routine will cause the release of value segments with the current brand. In order to optimize the releases caused by a call to JEDEMA, the storage of each value segment in memory is accompanied by the storage of its position (its memory address) in a system object (integer value segment). Thus, all the value segments associated with an identical brand are easily identifiable and their identification requires only a simple scan of an integer vector. The loop over the value segments is carried out in two stages: first, the collections are treated globally, then the simple objects and the value segments associated with the contiguous collections are released.

The brand of an object is updated when the JJECRS routine is called; if necessary, the KDESMA system object is resized (this object is referred to here by the name of the Fortran variable used to store its address within the program units).

It is routine JJLIDE that effectively liberates value segments. The first argument of this routine is the name of the caller, it determines the type of operation to be performed:

LIBE	standard release mechanism with condition, status, and brand review,
TASS	release mechanism with immediate write used when resetting files or in debug mode JEVEUX,
LIBF	mechanism used at the end of work when closing a JEVEUX base.

With regard to simple objects, this release does not pose any particular problem: the routine JJLIDE verifies that the mark associated with the value segment is identical to the current brand stored in the common/IADMJE/, it modifies the descriptors (state and status) of the value segment and assigns the associated mark to 0 and assigns the associated mark to 0, possibly it causes an unloading (JXECRO) and modifies the content of the memory address and disk address attributes. Releasing a dispersed collection object follows the same process, with the attributes being changed within the collection system objects. The release of a collection is more difficult, since system objects must be kept accessible in memory as long as a value segment associated with one of the collection objects is present in memory (used, downloadable, and even removable).