Sun Microsystems 2 manual Default Resource Allocation Policies, Revocation

Revocation

The revocation mechanism lets the system take a resource from one MIDlet to give the resource to another MIDlet. This second MIDlet is sometimes said to have preempted the resource from the first MIDlet. Resources are revoked without receiving any request from the MIDlet. The MIDlet might or might not be informed explicitly that the revocation is taking place, depending upon the type of resource being revoked.

After allocation by a MIDlet, many resources are deallocated explicitly by the MIDlet. For example, opening a socket allocates it, and closing the socket deallocates it, after which it can be reused by another MIDlet. If a socket is revoked, the underlying native resources are reclaimed, but the Java Socket object still exists. In this case, any subsequent operations on this Socket object results in an I/O error. The Java Wireless Client software doesn’t revoke sockets.

Revocation is not always so drastic. Sometimes it can occur almost transparently to the application. The device’s screen is a resource. When a MIDlet is put into the background, its access to the screen is revoked so that another MIDlet can paint to the screen. In this case, the only effect on the MIDlet might be that its hideNotify() method is called and that it no longer receives calls to the paint() method.

Another resource that can be revoked transparently is the CPU. When the CPU is revoked from a MIDlet, its threads simply stop running. When the MIDlet regains the CPU, its threads pick up where they left off.

Default Resource Allocation Policies

The Java Wireless Client software provides two preconfigured resource allocation policies: open and fixed. The open policy allows open competition among applications for resources. The fixed policy provides a fixed amount of resources for each application. Under the fixed policy, the reservation and limit for each resource are set to the same value. Setting the reservation and limit to the same value effectively creates a fixed partitioning of resources.

The policies have tradeoffs. Neither is clearly better than the other. Using the open resource policy might lead to unpredictable behavior. An application could at any time receive an error that a resource is not available. Users might find this behavior confusing. Under the fixed policy, if the amount of available resources is less than the reservation amount for a new MIDlet, the system refuses to start any more MIDlets. This occurs even if the actual amount of unused resources is sufficient for the new MIDlet, meaning valuable resources might go unused. However, this

24 Multitasking Guide • May 2007