SAP Basis Tech Supports

Symptom
It sometimes takes a long time to attach a virtual machine (VM) to a work process.
Other terms
VMC, VM container, virtual machine, performance, attach, mprotect, mmap
Reason and Prerequisites
To isolate the memory, the required areas of memory are “unlocked” when a VM is attached and are “locked” again when a VM is detached. This means an active VM can access only its own memory area. This occurs via the operating system functions mmap() and via mprotect() for a specific area of memory. The function mmap() displays a certain memory area in an address window. When a VM is detached, authorization for this window is revoked. The shared code cache of the just-in-time (JIT) compiler is kept static and is unlocked and locked via mprotect().
The attachment and detachment of individual memory segments occurs within a critical path. The operating system command for memory management in this path is relatively performance-intensive. This may cause serialization of the VMs and an unnecessarily long runtime for the attachment.
Solution
You can use a profile parameter to determine whether the memory is locked again when a VM is detached or whether it remains unlocked until the next attach. The mprotect can be completely avoided for the shared code cache.
Memory isolation is preserved from the VM’s point of view because a VM covers only its own memory area with its address window. Therefore, it is still not possible to access areas of another VM.

With one of the kernels:
Release 7.00 patch level 181
Release 7.01 patch level nn
Release 7.10 patch level nn
you can use the profile parameter
vmcj/memory_isolation =0
to simplify memory isolation. Set the parameter in production systems as long as there are no problems with memory protection violations (signal 11). We recommend that you keep memory isolation active in test systems so that you recognize any problems early. In addition, you may have unset the parameter for error analysis temporarily.