Java performance: Difference between revisions

Revision as of 02:52, 4 May 2024

Latest revision as of 05:07, 14 August 2025

(3 intermediate revisions by 3 users not shown)

Line 13:

}}</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 51 ⟶ 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 336 ⟶ 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 422 ⟶ 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 496 ⟶ 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