Tuning Locks of Oracle JRockit JVM
2011-02-23 23:44
435 查看
The interaction between Java threads affects the performance of your application. There are two ways to tune the interaction of threads:
By modifying the structure of your program code; for example, minimizing the amount of contention between threads
By using options in the Oracle JRockit JVM that affect how contention is handled when your application is running
This chapter describes the following topics:
Section 5.1, "Lock Profiling"
Section 5.2, "Disabling Spinning Against Fat Locks"
Section 5.3, "Adaptive Spinning Against Fat Locks"
Section 5.4, "Lock Deflation"
Section 5.5, "Lazy Unlocking"
For more information about how the JRockit JVM handles threads and locks, see the "Understanding Threads and Locks" section in Oracle JRockit Introduction to the JDK.
When lock profiling is enabled, you can view information about Java locks on the Lock Profiling tab in the JRockit Mission Control Client.
Note:
Lock profiling creates significant (approximately 20 percent) overhead processing when your Java application runs.
Two diagnostic commands are tied to the lock profile counters. To work, both require lock profiling to be enabled with the
The
The
For more information about diagnostic commands, see the Oracle JRockit Diagnostics and Troubleshooting Guide.
The option disables the fat lock spin code in Java, enabling threads that are trying to acquire a fat lock to go to a sleep state directly.
To enable adaptive lock spinning, use the
By default, adaptive spinning against fat locks is disabled. Note that whether threads that fail to take a particular fat lock spin or go to sleep can change at run time.
If you do not want fat locks to deflate, run the application with the following option:
With lock deflation disabled, a fat lock remains as a fat lock even after there are no threads waiting to take the lock.
You can also tune for when lock deflation is triggered. Specify, with the following option, the number of uncontended fat lock unlocks that occur before deflation:
When lazy unlocking is enabled, locks are not released when a critical section is exited. Instead, once a lock is acquired, the next thread that tries to acquire such a lock must ensure that the lock is or can be released. It does this by determining if the initial thread is using the lock. A shared lock converts to a normal lock and does not stay in lazy mode.
Lazy unlocking is enabled by default in the JRockit JVM for all garbage collection strategies except the deterministic garbage collector.
By modifying the structure of your program code; for example, minimizing the amount of contention between threads
By using options in the Oracle JRockit JVM that affect how contention is handled when your application is running
This chapter describes the following topics:
Section 5.1, "Lock Profiling"
Section 5.2, "Disabling Spinning Against Fat Locks"
Section 5.3, "Adaptive Spinning Against Fat Locks"
Section 5.4, "Lock Deflation"
Section 5.5, "Lazy Unlocking"
For more information about how the JRockit JVM handles threads and locks, see the "Understanding Threads and Locks" section in Oracle JRockit Introduction to the JDK.
5.1 Lock Profiling
You can configure the JRockit Flight Recorder to collect and analyze information about the locks and the contention that occurred while the Flight Recorder was recording. To do this, add the following option when you start your application:-XX:+UseLockProfiling
When lock profiling is enabled, you can view information about Java locks on the Lock Profiling tab in the JRockit Mission Control Client.
Note:
Lock profiling creates significant (approximately 20 percent) overhead processing when your Java application runs.
Two diagnostic commands are tied to the lock profile counters. To work, both require lock profiling to be enabled with the
-XX:+UseLockProfilingoption. These are used with the
jrcmdutility:
The
lockprofile_printcommand prints the current values of the lock profile counters.
The
lockprofile_resetcommand resets the current values of the lock profile counters.
For more information about diagnostic commands, see the Oracle JRockit Diagnostics and Troubleshooting Guide.
5.2 Disabling Spinning Against Fat Locks
Spinning against a fat lock is generally beneficial. However, in some instances such as when you have locks that create long waiting periods and high contention it can be expensive in terms of performance. You can turn off spinning against a fat lock and eliminate a potential performance degradation with the following option:-XX:-UseFatSpin
The option disables the fat lock spin code in Java, enabling threads that are trying to acquire a fat lock to go to a sleep state directly.
5.3 Adaptive Spinning Against Fat Locks
You can let the JVM decide whether threads should spin against a fat lock or not (and directly go into sleeping state when failing to take it).To enable adaptive lock spinning, use the
-XX:+UseAdaptiveFatSpinoption.
By default, adaptive spinning against fat locks is disabled. Note that whether threads that fail to take a particular fat lock spin or go to sleep can change at run time.
5.4 Lock Deflation
If the amount of contention on a fat lock is small, the lock converts to a thin lock. This process is called lock deflation. Thin locks have higher performance for uncontended locks. Therefore, lock deflation is enabled by default.If you do not want fat locks to deflate, run the application with the following option:
-XX:-UseFatLockDeflation
With lock deflation disabled, a fat lock remains as a fat lock even after there are no threads waiting to take the lock.
You can also tune for when lock deflation is triggered. Specify, with the following option, the number of uncontended fat lock unlocks that occur before deflation:
-XX:FatLockDeflationThreshold=NumberOfUnlocks
5.5 Lazy Unlocking
Lazy unlocking is intended for applications with many nonshared locks. Note that it can introduce performance penalties with applications that have many short-lived but shared locks.When lazy unlocking is enabled, locks are not released when a critical section is exited. Instead, once a lock is acquired, the next thread that tries to acquire such a lock must ensure that the lock is or can be released. It does this by determining if the initial thread is using the lock. A shared lock converts to a normal lock and does not stay in lazy mode.
Lazy unlocking is enabled by default in the JRockit JVM for all garbage collection strategies except the deterministic garbage collector.
相关文章推荐
- Understanding Threads and Locks of Oracle JRockit JVM
- Oracle overview of oracle database performance tuning
- Tuning All Layers of the Oracle E-Business Suite
- Tuning 01 Overview of Oracle Performance Tuning
- 优化Oracle JRockit JVM 虚拟机
- oracle lock 02 - Use of Locks
- 访问数据库数据过大:java.lang.OutOfMemoryError: Java heap space :设置jvm虚拟机heap大小
- Oracle Form---Types of Key Flexeld Forms
- get the last date of a month in oracle
- Oracle Java Archive(All release of Java SE Version)
- Zero Downtime Upgrade of Oracle 10g to Oracle 11g Using GoldenGate — 3
- Function of Oracle
- 调优JVM内存,并解决OutOfMemoryError,StackOverflowError等异常问题
- two scripts - monitoring the usage of rollback segments of Oracle Database
- Making Best Out Of Oracle Databases Using ODP.net - Part I
- 【原创】Eclipse无法启动,Version 1.4 of the JVM is not suitable for this project.Version 1.5
- Oracle Linux Reference Index of Security Vulnerability bug fixes, CVE IDs and Oracle Linux Errata
- The sequence of the learning ORACLE.
- Oracle SQL developer Unable to create an instance of the Java Virtual Machine
- Oracle OFA 简介