Content deleted Content added
No edit summary |
m HTTP to HTTPS for Blogspot |
||
| (25 intermediate revisions by 11 users not shown) | |||
Line 1:
{{Short description|Aspect of Java programming language}}
{{Update|reason=Is missing the many improvements in Java 8, 11, 17, 21, ... |date=
{{Use mdy dates|date=October 2018}}
In [[software development]], the programming language [[Java (programming language)|Java]] was historically considered slower than the fastest [[
Since the late 1990s, the execution speed of Java programs improved significantly via introduction of [[just-in-time compilation]] (JIT) (in 1997 for [[Java version history|Java 1.1]]),<ref name="
| url=http://www.symantec.com/about/news/release/article.jsp?prid=19970407_03
| archive-url=https://web.archive.org/web/20100628171748/http://www.symantec.com/about/news/release/article.jsp?prid=19970407_03
| url-status=dead
| archive-date=June 28, 2010
| title=Symantec's Just-In-Time Java Compiler To Be Integrated Into Sun JDK 1.1
}}</ref><ref name=cnet1998/><ref>{{cite web
| url=http://grnlight.net/index.php/programming-articles/116-java-gets-four-times-faster-with-new-symantec-just-in-time-compiler
| archive-url=https://archive.today/20140527181040/http://grnlight.net/index.php/programming-articles/116-java-gets-four-times-faster-with-new-symantec-just-in-time-compiler
| title=Java gets four times faster with new Symantec just-in-time compiler}}</ref> the addition of language features supporting better code analysis, and optimizations in the JVM (such as [[HotSpot (virtual machine)|HotSpot]] becoming the default for [[Sun Microsystems|Sun]]'s JVM in 2000). Hardware execution of Java bytecode, such as that offered by ARM's [[Jazelle]], was also explored to offer significant performance improvements.▼
| url-status=usurped
| archive-date=May 27, 2014
▲| title=Java gets four times faster with new Symantec just-in-time compiler}}</ref> the addition of language features supporting better code analysis, and optimizations in the JVM (such as [[HotSpot (virtual machine)|HotSpot]] becoming the default for [[Sun Microsystems|Sun]]'s JVM in 2000). Sophisticated [[garbage collection (computer science)|garbage collection]] strategies were also an area of improvement. Hardware execution of Java bytecode, such as that offered by ARM's [[Jazelle]], was
The [[Computer performance|performance]] of a [[Java bytecode]] compiled Java program depends on how optimally its given tasks are managed by the host [[Java virtual machine]] (JVM), and how well the JVM exploits the features of the [[computer hardware]] and [[operating system]] (OS) in doing so. Thus, any Java [[Software performance testing|performance test]] or comparison has to always report the version, vendor, OS and hardware architecture of the used JVM. In a similar manner, the performance of the equivalent natively compiled program will depend on the quality of its generated machine code, so the test or comparison also has to report the name, version and vendor of the used compiler, and its activated [[compiler optimization]] directives.
==Virtual machine optimization methods==
Line 20 ⟶ 25:
===Just-in-time compiling===
{{Further|Just-in-time compilation|HotSpot (virtual machine)}}
Early JVMs always interpreted [[Java bytecode]]s. This had a large performance penalty of between a factor 10 and 20 for Java versus C in average applications.<ref>{{cite web | url=http://www.shudo.net/jit/perf/ | title=Performance Comparison of Java/.NET Runtimes (Oct 2004) }}</ref> To combat this, a just-in-time (JIT) compiler was introduced into Java 1.1. Due to the high cost of compiling, an added system called [[HotSpot (virtual machine)|HotSpot]] was introduced in Java 1.2 and was made the default in Java 1.3. Using this framework, the [[Java virtual machine]] continually analyses program performance for ''hot spots'' which are executed frequently or repeatedly. These are then targeted for [[Optimization (computer science)|optimizing]], leading to high performance execution with a minimum of [[Overhead (computing)|overhead]] for less performance-critical code.<ref>
{{Cite web
| url=https://weblogs.java.net/blog/kohsuke/archive/2008/03/deep_dive_into.html
Line 38 ⟶ 43:
| 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 49 ⟶ 54:
| publisher=[[Sun Microsystems]]
| access-date=April 20, 2008}}</ref><ref>{{Cite web
| url=
| title=Lang.NET 2008: Day 1 Thoughts
| quote=''Deoptimization is very exciting when dealing with performance concerns, since it means you can make much more aggressive optimizations...knowing you'll be able to fall back on a tried and true safe path later on''
Line 83 ⟶ 88:
====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 89 ⟶ 94:
As the Java library does not know which methods will be used by more than one thread, the standard library always locks [[block (programming)|blocks]] when needed in a multithreaded environment.
Before Java 6, the virtual machine always [[Lock (computer science)|locked]] objects and blocks when asked to by the program, even if there was no risk of an object being modified by two different threads at once. For example, in this case, a local {{code|
<syntaxhighlight lang="java">
public String getNames() {
final Vector<String> v = new Vector<>();
v.add("Me");
v.add("You");
Line 117 ⟶ 122:
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 126 ⟶ 131:
==History of performance improvements==
{{Update|section|date=
{{Further|Java version history}}
Apart from the improvements listed here, each release of Java introduced many performance improvements in the JVM and Java [[application programming interface]] (API).
JDK 1.1.6: First [[just-in-time compilation]] ([[NortonLifeLock|Symantec]]'s JIT-compiler)<ref name="
J2SE 1.2: Use of a [[Garbage collection (computer science)#Generational GC (aka Ephemeral GC)|generational collector]].
Line 157 ⟶ 162:
| 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 ⟶ 228:
==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>
Line 295 ⟶ 300:
Results for [[Benchmark (computing)|microbenchmarks]] between Java and C++ highly depend on which operations are compared. For example, when comparing with Java 5.0:
*32- and 64
| url=http://www.ddj.com/java/184401976?pgno=2
| title=Microbenchmarking C++, C#, and Java: 32-bit integer arithmetic
Line 305 ⟶ 310:
| publisher=[[Dr. Dobb's Journal]]
| date=July 1, 2005
| access-date=January 18, 2011}}</ref> [[Input/output|
| url=http://www.ddj.com/java/184401976?pgno=15
| title=Microbenchmarking C++, C#, and Java: File I/O
| publisher=[[Dr. Dobb's Journal]]
| date=July 1, 2005
| access-date=January 18, 2011}}</ref> and [[
| url=http://www.ddj.com/java/184401976?pgno=17
| title=Microbenchmarking C++, C#, and Java: Exception
Line 316 ⟶ 321:
| date=July 1, 2005
| access-date=January 18, 2011}}</ref> have a similar performance to comparable C++ programs
*Operations on [[Array data type|
| url=http://www.ddj.com/java/184401976?pgno=19
| title=Microbenchmarking C++, C#, and Java: Array
| publisher=[[Dr. Dobb's Journal]]
| date=July 1, 2005
| access-date=January 18, 2011}}</ref>
*The performance of [[
| url=http://www.ddj.com/java/184401976?pgno=19
| title=Microbenchmarking C++, C#, and Java: Trigonometric functions
Line 334 ⟶ 339:
===Multi-core performance===
The scalability and performance of Java applications on multi-core systems is limited by the object allocation rate. This effect is sometimes called an "allocation wall".<ref>Yi Zhao, Jin Shi, Kai Zheng, Haichuan Wang, Haibo Lin and Ling Shao, [http://portal.acm.org/citation.cfm?id=1640116 Allocation wall: a limiting factor of Java applications on emerging multi-core platforms], Proceedings of the 24th ACM SIGPLAN conference on Object oriented programming systems languages and applications, 2009.</ref> However, in practice, modern garbage collector algorithms use multiple cores to perform garbage collection, which to some degree alleviates this problem. Some garbage collectors are reported to sustain allocation rates of over a gigabyte per second,<ref>
Automatic memory management in Java allows for efficient use of lockless and immutable data structures that are extremely hard or sometimes impossible to implement without some kind of a garbage collection.{{citation needed|date=September 2018}} Java offers a number of such high-level structures in its standard library in the java.util.concurrent package, while many languages historically used for high performance systems like C or C++ are still lacking them.{{citation needed|date=September 2017}}
Line 420 ⟶ 425:
| access-date=February 15, 2008}}
</ref><ref>{{Cite web
|url =
|title = Efficient Cooperation between Java and Native Codes - JNI Performance Benchmark
|last = Kurzyniec
Line 430 ⟶ 435:
|archive-date = February 14, 2005
|df = dmy-all
}}</ref>{{sfn|Bloch|2018|loc=Chapter §11 Item 66: Use native methods judiciously|p=285}} [[Java Native Access]] (JNA) provides [[Java (programming language)|Java]] programs easy access to native [[Shared library|shared libraries]] ([[dynamic-link library]] (DLLs) on Windows) via Java code only, with no JNI or native code. This functionality is comparable to Windows' Platform/Invoke and [[Python (programming language)|Python's]] ctypes. Access is dynamic at runtime without code generation. But it has a cost, and JNA is usually slower than JNI.<ref>{{Cite web
|url = https://jna.dev.java.net/#performance
|title = How does JNA performance compare to custom JNI?
Line 494 ⟶ 499:
|author1=Chris Nyberg |author2=Mehul Shah | access-date=November 30, 2010
}}</ref><ref name=googlemapreduce>{{cite web
| url=
| title=Sorting 1PB with MapReduce
| date=November 21, 2008
Line 513 ⟶ 518:
*[[Java ConcurrentMap]]
==
{{Reflist|2|refs=
<ref name=cnet1998>
Line 520 ⟶ 525:
| date= May 12, 1998 |access-date= November 15, 2015}}</ref>
}}
==References==
*{{cite book |last=Bloch| first=Joshua| title= "Effective Java: Programming Language Guide" | publisher=Addison-Wesley | edition=third | isbn=978-0134685991| date=2018}}
==External links==
| |||