vmcj/nested_lock_loops 
When requesting VM-wide locks (Shared Locks), the following points must be considered:
If another lock is requested within an area protected by a shared lock, and the wrong sequence is used, a deadlock may result.
If a VM-wide garbage collection (Shared Garbage Collection) is active, a VM that has just requested a shared lock must first contribute to the garbage collection before it can receive the shared lock. To enable this to happen, the lock request is not allowed to block.
If a timeout occurs at the first attempt to receive the lock, the VM enters a loop during which control is relinquished for a short time, and the lock request is repeated.
The number of loops can be limited with the parameter vmcj/nested_lock_loops:
Properties
Work area | VM Container |
Unit | Integer value |
Standard value | -1 |
Dynamically changeable | Local and on all servers |
Value Range and Syntax
The following values are permitted:
-1: Endless attempts are made to set the lock.
n>= 0: Maximum number of attempts to set the lock. Each attempt lasts for about one second. If the lock still could not be set after n number of attempts, the lock request is rejected.
SAP Recommendation
Only change the parameter if you are sure that there really is a deadlock, and then try to solve the problem.