day2Jrockit.docx

1、day2JrockitJrockit时间：81. Explain Oracle JRockit JDKAbout the JDK The JRockit JVM is a high-performance JVM developed to ensure reliability, scalability, manageability, and flexibility for Java applications. The JRockit JVM provides improved performance for Java applications deployed on Intel 32-bit

2、(Xeon) and 64-bit (Xeon and SPARC) architectures at significantly lower costs to the enterprise. Further, it is the only enterprise-class JVM optimized for Intel architectures, providing seamless interoperability across multiple hardware and operating system configurations. The JRockit JVM enables y

3、our Java applications to run optimally on Windows and Linux operating systems (both 32-bit and 64-bit architectures). The JRockit JVM is especially well-suited for running Oracle WebLogic Server.The JRockit JVM is one component of the Oracle JRockit Java development kit (JDK). In addition to the JRo

4、ckit JVM, the JDK is comprised of the Java Runtime Environment (JRE), which contains the JVM and Java class libraries (as specified by the Java Platform, Standard Edition 6 API Specification), as well as a set of development tools, such as a compiler. The JRockit JDK is compatible with J2SE 5.0 and

5、Java SE 6.2. Use JIT Compilation and Optimizations just-in-time compilation (JIT), also known as dynamic translation, is a method to improve the runtime performance of computer programs. Traditionally, computer programs had two modes of runtime operation, either interpreted or static (ahead-of-time)

6、 compilation. Interpreted code is translated from a high-level language to a machine code continuously during every execution, whereas statically compiled code is translated into machine code before execution, and only requires this translation once.JIT compilers represent a hybrid approach, with tr

7、anslation occurring continuously, as with interpreters, but with caching of translated code to minimize performance degradation. It also offers other advantages over statically compiled code at development time, such as handling of late-bound data types and the ability to enforce security guarantees

8、.JIT builds upon two earlier ideas in run-time environments: bytecode compilation and dynamic compilation. It converts code at runtime prior to executing it natively, for example bytecode into native machine code.Several modern runtime environments, such as Microsofts .NET Framework and most impleme

9、ntations of Java, rely on JIT compilation for high-speed code execution.Step 1: JIT CompilationThe first step in the machine-code generation process is just-in-time (JIT) compilation. JRockit does not include an interpreter; so the JIT compilation of the byte code into native machine code has to occ

10、ur before a method executes. The JIT compilation is performed the first time a Java method is called.The JIT compiler is fast and generates moderately efficient code. This is necessary to enable the Java application to start and run quickly. Subsequently, profiling reveals frequently called methods

11、(hot spots) that require further optimization. The JRockit approachJIT compilation and no interpreterresults in relatively longer startup times, but even if the JIT compilation results in only moderately efficient code, the generated code is still significantly faster than interpreted code.Step 2: T

12、hread MonitoringDuring the second step of the machine-code generation process, the JRockit JVM uses a sophisticated, low-cost, sampling based technique to identify which functions merit optimization: a sampler thread wakes up periodically and checks the status of several application threads. It iden

13、tifies what each thread is executing and logs some execution history. This information is tracked for all the methods; when the information indicates that a method is heavily used (hot), that method is earmarked for optimization. Usually, a flurry of such optimization opportunities occur in the appl

14、ications early run stages, with the rate slowing down as execution continues.Step 3: Code OptimizationCode optimization is a process by which commonly-executed code is recompiled to make it run more efficiently.The first time that the JRockit JVM runs a method, the method is compiled into machine co

15、de. This compilation is quick, but the resulting code is not as efficient as it could be. This code is acceptable for methods that are run once and discarded; however, if a method is used repeatedly, the system can get a performance boost if the code for that particular method is regenerated in a mo

16、re efficient way.The JRockit JVM optimizes these commonly-executed (hot) methods to make the code as efficient as possible. The optimization runs in the background and does not interfere with the running application.3. Manage Memory M number of static collectors that can be started either by specify

17、ing the actual collector (-Xgc:) or by default, as determined by the JVM mode you select at startup. Command line option: -Xns:The size of the nursery has an impact on allocation speed, garbage collection frequency and garbage collection times. A small nursery will become full quickly and must be ga

18、rbage collected more often, while garbage collection of a large nursery takes slightly longer time. A nursery that is so small that few or no objects have died before a young collection is started is of very little use, and neither is a nursery that is so large that no young collections are performe

19、d between garbage collections of the whole heap that are triggered due to allocation of large objects in old space.Setting a Pause Target for Deterministic ModeCommand line option: -XpauseTarget:The deterministic mode uses a pause target for optimizing the pause times. The pause target impacts the a

20、pplication throughput, as a lower pause target will inflict more overhead on the memory management system. Set the pause target as high as your application can tolerate. The garbage collector will aim on keeping the garbage collection pauses below the given pause target.Setting a Pause Target for Pa

21、usetime ModeCommand line option: -XpauseTarget:The pausetime mode uses a pause target for optimizing the pause times. The pause target impacts the application throughput, as a lower pause target will inflict more overhead on the memory management system. Set the pause target as high as your applicat

22、ion can tolerate.4. Manage Threads and Locks Understanding ThreadsA java application consists of one or more threads that run Java code. The entire JVM process consists of the Java threads and some JVM internal threads, for example one or more garbage collection threads, a code optimizer thread and

23、one or more finalizer threads.From the operating systems point of view the Java threads are just like any application threads. Scheduling of the threads is handled by the operating system, as well as thread priorities.Within Java, the Java threads are represented by thread objects. Each thread also

24、has a stack, used for storing runtime data. The thread stack has a specific size. If a thread tries to store more items on the stack than the stack size allows, the thread will throw a stack overflow error.Understanding LocksWhen threads in a process share and update the same data, their activities

25、must be synchronized to avoid errors. In Java, this is done with the synchronized keyword, or with wait and notify. Synchronization is achieved by the use of locks, each of which is associated with an object by the JVM. For a thread to work on an object, it must have control over the lock associated

26、 with it, it must “hold” the lock. Only one thread can hold a lock at a time. If a thread tries to take a lock that is already held by another thread, then it must wait until the lock is released. When this happens, there is so called “contention” for the lock.There are four different kinds of locks

27、: Fat locks: A fat lock is a lock with a history of contention (several threads trying to take the lock simultaneously), or a lock that has been waited on (for notification). Thin locks: A thin lock is a lock that does not have any contention. Recursive locks: A recursive lock is a lock that has bee

28、n taken by a thread several times without having been released. Lazy locks: A lazy lock is a lock that is not released when a critical section is exited. Once a lazy lock is acquired by a thread, other threads that try to acquire the lock have to ensure that the lock is, or can be, released. Lazy lo

29、cks are used by default in Oracle JRockit JVM 27.6. In older releases, lazy locks are only used if you have started the JVM with the -XXlazyUnlocking option.A thin lock can be inflated to a fat lock and a fat lock can be deflated to a thin lock. The JRockit JVM uses a complex set of heuristics to de

30、termine when to inflate a thin lock to a fat lock and when to deflate a fat lock to a thin lock.Lock ChainsSeveral threads can be tied up in what is called lock chains. Although they appear somewhat complex, lock chains are fairly straightforward. They can be defined as follows: Threads A and B form

31、 a lock chain if thread A holds a lock that thread B is trying to take. If A is not trying to take a lock, then the lock chain is “open.” If A-B is a lock chain, and B-C is a lock chain, then A-B-C is a more complete lock chain. If there is no additional thread waiting for a lock held by C, then A-B-C is a complete and open lock chain.Lock Chain TypesThe JRockit JVM analyzes the threads and forms complete lock chains. There are three possible kinds of lock chains: Open, Deadlocked and Blocked lock chains.Open ChainsOpen lock chains represent a straight dependency, thread A