Resource Management in the VM Container 

When a user processes a Java request the following components and resources are involved:

●     The work processes map a free Java VM from the VM Pool (attach). Once the request has been processed, they the Java VM back in the pool (detach).

●     The user contexts are located in the shared memory.

●     The Java VMs use a user context and process the request (the same as with ABAP requests).

From the isolation perspective it would make sense to start a Java VM for each user.Due to the high memory requirement and the time needed for a Java VM to start up, there is a VM pool from which VMs are attached to work processes as and when required. This pool must contain more VMs than there are configured work processes, because in certain cases, a VM remains fixed to a user if it does not urgently need the work process (waits for the completion of an I/O operation)

The shared memory contains data that is shared among all the VMs. The data is:

●     Shared classes, that is, Java classes that were initially loaded by one of the VMs, and are now available to all the VMs (engine shared data; similar to ABAP PXA). The shared classes contain the byte code of the classes, their constant pool, and the native code generated by the Just-In-Time Compiler.

●     Configuration data needed by all VMs.

The shared memory also contains the user contexts that are copied to the VM of the work process as and when required.

Unlike with ABAP, the user contexts are not attached; they are actually copied into the VM, and copied back again once the request has been processed. This is necessary, since with every change to the user contexts references to local objects could potentially be used, and these local references would not be valid in another VM. For this reason the object tree must be updated each time.

If the size of the context exceeds the size specified, the VM is reserved for the user. Then although, it is no longer rollable, the context does not have to be copied into the VM any more.

The VM remains in the work process for as long as it can do something, that is, one of its threads is running. If no thread can be run (for example, because the request has been processed and the VM is waiting for the next request), the VM is detached from the work process. Depending on the status of the VM it is put into the VM pool (so that it can be used for any number of new requests), or it remains assigned to the user (I/O case, see above).

Of course, several user contexts can be processed at the same time in different work processes, as is the case with ABAP too.