Oipf standard translation (DAE) -- 4.4 Resource Management

4.4 Resource Management
This section describes how resources (including non-granular resources such as memory and display area) are shared between multiple applications that may be running simultaneously. applications shocould be able to tolerate the loss of scarce resources if they are needed by another application, and shocould follow current industry best practises in order to minimize the resources they consume.
This specification is silent about the mechanisms for sharing resources between Dae applications, PAE applications and
Other applications running on the oitf. In the remainder of this section and this document, the term application refers solely to Dae applications

4.4 Resource Management

This section describes how resources (including unconventional resources such as memory and display areas) are shared among multiple applications running at the same time. If another program needs resources

Order should be able to tolerate the loss of scarce resources. Applications should follow industry practices to minimize resource consumption.

This specification does not elaborate (silent) on the Dae program. The PAE program section shares resources among other applications running on oitf. In this section and the rest of this document, terms

Application refers to the Dae application.

 

4.4.1 application lifecycle issues
If an application attempts to start and not enough resources are available, the application with the lowest priority may be terminated until sufficient resources are available for the new application to execute or until no applications with a lower priority are running. applications without a priority associated with them (e.g. applications started by the DRM agent, see section 5.1.1.6) shall be assumed to have a priority of 0x7f.

Applications may register a listener for applicationunloaded events (see section 7.2.1.3) to receive notification
The termination of a child application.
Failure to load an asset (e.g. an Image File) or CSS file due to a lack of memory shall have no effect on the lifecycle of an application, but may result in visual artefacts (e.g. images not being displayed ). failure to load an HTML file due to a lack of memory may cause the application to be terminated.

 

4.4.1 application lifecycle issues

If an application does not have enough resources (provided) to start, the application with the lowest priority may be terminated (to sell resources) until the new application has enough resources to execute

Stop (stop terminating the program sequence with the lowest priority), or wait until the program with no lower priority is run again (otherwise, the program with the lowest priority will be terminated ). If an application

If there is no corresponding priority (attribute) (for example, for an application started by the DRM proxy, see section 5.1.1.6), its priority is 0x7f by default.

Generally, an application registers a listener for the applicationunloaded event (as described in section 7.2.1.3) to receive the notification (Message) of the subprogram termination ). The loading failure of elements (objects) or CSS files (pages or applications) due to insufficient memory should not affect the life cycle of the application, but may cause visual effects (fragments cannot be displayed ). Due to insufficient memory, loading of HTML files fails, which may lead to application termination.

 

4.4.2 caching of Application Files
Application Files may be cached on the specified er in order to improve performance; this specification is silent about
Use of any particle caching strategy. For packaged applications, the entire package shall be retained (in either
Packaged or unpackaged form) until the application has terminated.

4.4.2 application file cache (storage)
The recipient (oitf) can temporarily cache the files of the application to improve its performance. This requirement does not involve the caching mechanism for other specific content (I do not know if it is true or not ). For packaged applications (similar to jar ?), The entire package should be retained (for unwrapped or unwrapped packages) until the application is terminated.

4.4.3 memory usage
Applications shocould use current industry best practises to avoid memory leaks and to free memory when it is no
Longer Required. In participates, applications shall unregister all event listeners before termination, and shoshould
Unregister them as soon as they are no longer required.

Where available, applications shall use explicit destructor functions to indicate to the platform that resources may be re-used by other applications.
Applications may use the GC () method on the application/oipfapplicationmanager embedded object
Provide hints to the oitf that a garbage collection cycle shoshould be carried out. The oitf is not required to act on these hints.

The lowmemory event described in section 7.2.1.3 shall be generated when the runner er is running low on memory.
The amount of free memory that causes this event to be generated is implementation dependent.

Applications may register a listener for these events in order to handle low-memory situations as they choose best.

 

4.4.3 memory usage

Applications should use the best design habits in the industry to avoid memory leaks, and should be released in a timely manner when they do not use the memory. Pay special attention to the fact that the application should be terminated

Destroy all event listening programs before or when they are no longer in use.

If possible (with conditions), the application should use clear destructor to release resources for other programs running on the platform.

The application can use the GC () method in the application/oipfapplicationmanager embedded object to notify the oitf platform's garbage memory collection mechanism to release the memory. Oitf does not require such a mechanism.

The lowmemory (with too little memory) event defined in 7.2.1.3 should be generated when there is a small amount of memory remaining during the receiver (oitf) running process. The specific amount of memory for which an event is generated depends on the relevant implementation (according to the platform definition: ). Generally, an application registers a listener for this event to handle the event when the memory is low ).

 

4.4.4 instantiating embedded objects and claiming scarce system resources

The objects defined in section 7 of this specification are embedded objects. These are typically instantiated through the standard DOM 2 methods for creating HTML objects or the oipfobjectfactory as defined in section 7.1.

All embedded objects as defined in section 7 shall not claim scarce system resources (such as a hybrid tuner) at the time of Instantiation. hence, instantiation shall not fail if the object type is supported (and sufficient memory is
Available ).

For each embedded object for which scarce resource conflicts may be a problem, the State digoal and the accompanying text define how to deal with claiming (and releasing) scarce system resources. note that scarce resources shall be released, when the respective embedded object gets destroyed (e.g. during a transition to another HTML document, should t in cases described for the optional 'persist 'property of a/V objects ). if there are no references (anymore) to an embedded object as defined in section 7 (e.g. after removing the object from the DOM tree), then the scarce system resources claimed by the embedded object shoshould be released.

 

Note: instantiated embedded objects do not have to be added to the DOM tree in order for their javascript API to be usable ).

4.4.4 (PAGE) instantiation and acquisition of embedded objects (scrace in short supply) system resources the objects defined in section 7th of this specification are embedded objects. It is typically instantiated by using the standard dom2 method to Create HTML objects or creating oipfobjectfactory objects (defined in section 7.1. All embedded objects (defined in section 7th) do not require (in short supply) system resources during instantiation. Therefore, as long as the object type is supported, the installation will not fail (with enough memory)

Not when provided ).

For each embedded object, resource request conflicts may be a problem. The block diagram and related texts define how to obtain (or release) scarce system resources. If each embedded object has been destroyed

The requested resources should be released (for example, when you transfer to another HTML document, you should remove the/V object that still exists ). If the embedded object defined in section 7th is no longer used (such as removing and modifying the object from the DOM tree), the requested system resources should be released.

 

Note: To ensure the availability of JS APIs, the instantiated applications do not have to be inserted into the Dom ).