Java performance: Difference between revisions

Revision as of 03:14, 19 March 2024

Latest revision as of 05:07, 14 August 2025

(5 intermediate revisions by 4 users not shown)

Line 3:

{{Use mdy dates|date=October 2018}}

In [[software development]], the programming language [[Java (programming language)|Java]] was historically considered slower than the fastest [[ProgrammingThird-generation languageprogramming generationslanguage|third-generation]] [[Type system|typed]] languages such as [[C (programming language)|C]] and [[C++]].<ref>{{Cite web|url=http://www.scribblethink.org/Computer/javaCbenchmark.html|title=Java versus C++ benchmarks}}</ref> In contrast to those languages, Java compiles by default to a [[Java Virtual Machine]] (JVM) with operations distinct from those of the actual computer hardware. Early JVM implementations were [[Interpreter (computing)|interpreters]]; they simulated the virtual operations one-by-one rather than translating them into [[machine code]] for direct hardware execution.

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="symantec.comSymantec">{{Cite web

| 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

| 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 explored but not deployed.

Line 48 ⟶ 54:

| publisher=[[Sun Microsystems]]

| access-date=April 20, 2008}}</ref><ref>{{Cite web

| url=httphttps://headius.blogspot.com/2008/01/langnet-2008-day-1-thoughts.html

| 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 129 ⟶ 135:

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="symantec.comSymantec"/><ref name="symantec compiler">{{Cite web|last1=Mckay|first1=Niali|url=http://linxdigital.ca/java-four-times-faster-symantec-compiler.html|title=Java gets four times faster with new Symantec just-in-time compiler}}</ref>

J2SE 1.2: Use of a [[Garbage collection (computer science)#Generational GC (aka Ephemeral GC)|generational collector]].

Line 333 ⟶ 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>[{{Cite web |url=http://www.azulsystems.com/sites/default/files/images/c4_paper_acm_0.pdf |title=C4: The Continuously Concurrent Compacting Collector] |access-date=October 29, 2013 |archive-date=August 9, 2014 |archive-url=https://web.archive.org/web/20140809222603/http://www.azulsystems.com/sites/default/files/images/c4_paper_acm_0.pdf |url-status=dead }}</ref> and there exist Java-based systems that have no problems scaling to several hundreds of CPU cores and heaps sized several hundreds of GB.<ref>[https://www.theregister.co.uk/2007/06/15/azul_releases_7200_systems/ Azul bullies Java with 768 core machine]</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 419 ⟶ 425:

| access-date=February 15, 2008}}

</ref><ref>{{Cite web

|url = httphttps://janet-project.sourceforge.net/papers/jnibench.pdf

|title = Efficient Cooperation between Java and Native Codes - JNI Performance Benchmark

|last = Kurzyniec

Line 493 ⟶ 499:

|author1=Chris Nyberg |author2=Mehul Shah | access-date=November 30, 2010

}}</ref><ref name=googlemapreduce>{{cite web

| url=httphttps://googleblog.blogspot.com/2008/11/sorting-1pb-with-mapreduce.html

| title=Sorting 1PB with MapReduce

| date=November 21, 2008