Content deleted Content added
→Escape analysis and lock coarsening: Add code formatting |
Fixed grammar, fixed formatting |
||
Line 38:
| publisher=[[Intel Corporation]]
| access-date=June 22, 2007}}</ref>
Some benchmarks show a 10-fold speed gain by this means.<ref>This [http://www.shudo.net/jit/perf/ article] shows that the performance gain between interpreted mode and Hotspot amounts to more than a factor of 10.</ref> However, due to time constraints, the compiler cannot fully optimize the program, and thus the resulting program is slower than native code alternatives.<ref>[http://www.itu.dk/~sestoft/papers/numericperformance.pdf Numeric performance in C, C# and Java ]</ref><ref>[http://www.cherrystonesoftware.com/doc/AlgorithmicPerformance.pdf
===Adaptive optimizing===
Line 83:
====Escape analysis and lock coarsening====
{{Further|Lock (computer science)|Escape analysis}}
Java is able to manage [[Thread (computer science)|multithreading]] at the language level. Multithreading
However, programs that use multithreading need to take extra care of [[Object (computer science)|objects]] shared between threads, locking access to shared [[Method (computer science)|methods]] or [[block (programming)|blocks]] when they are used by one of the threads. Locking a block or an object is a time-consuming operation due to the nature of the underlying [[operating system]]-level operation involved (see [[concurrency control]] and [[Lock (computer science)#Granularity|lock granularity]]).
Line 117:
Before [[Java version history|Java 6]], [[Register allocation|allocation of registers]] was very primitive in the ''client'' virtual machine (they did not live across [[Block (programming)|blocks]]), which was a problem in [[CPU design]]s which had fewer [[processor register]]s available, as in [[x86]]s. If there are no more registers available for an operation, the compiler must [[register spilling|copy from register to memory]] (or memory to register), which takes time (registers are significantly faster to access). However, the ''server'' virtual machine used a [[Graph coloring|color-graph]] allocator and did not have this problem.
An optimization of register allocation was introduced in Sun's JDK 6;<ref>[http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6320351 Bug report: new register allocator, fixed in Mustang (JDK 6) b59]</ref> it was then possible to use the same registers across blocks (when applicable), reducing accesses to the memory.
====Class data sharing====
Line 157:
| publisher=Sun Microsystems
|last=Haase|first=Chet
| quote=''At the OS level, all of these megabytes have to be read from disk, which is a very slow operation. Actually, it's the seek time of the disk that's the killer; reading large files sequentially is relatively fast, but seeking the bits that we actually need is not.
|date= May 2007| access-date=July 27, 2007}}</ref>
*Parts of the platform needed to execute an application accessed from the web when JRE is not installed are now downloaded first. The full JRE is 12 MB, a typical Swing application only needs to download 4 MB to start. The remaining parts are then downloaded in the background.<ref>{{Cite web
Line 223:
==Comparison to other languages==
Objectively comparing the performance of a Java program and an equivalent one written in another language such as [[C++]] needs a carefully and thoughtfully constructed benchmark which compares programs completing identical tasks.
Java is often [[Just-in-time compilation|compiled just-in-time]] at runtime by the Java [[virtual machine]], but may also be [[Ahead-of-time compilation|compiled ahead-of-time]], as is C++. When compiled just-in-time, the micro-benchmarks of [[The Computer Language Benchmarks Game]] indicate the following about its performance:<ref>
| |||