Ask not what you can do for your JVM, ask what your JVM

can do for youEtt långsamt mellanlager eller har vi

någon nytta av den sett till prestanda?

Mattias Isegran Bergander

Hur kom denna hit nu då...Hur kom denna hit nu då...

Och den här?!

Det u�ppenbara svaret...

Kommer ni ihåg Java 1.0/1.1?

Jämför med nu...

(förutom att datorerna är snabbare)

Historik

1995: Java 1.0 1996: Java 1.11998: Java 1.22000: Java 1.32002: Java 1.42004: Java 1.52006: Java 1.6.........2011: Java 1.7

Historik: Prestanda

1995: Java 1.0 1996: Java 1.1 Symantec JIT1998: Java 1.2 Generational GC1999: Hotspot2000: Java 1.3 Hotspot default, Math, BigInteger2002: Java 1.4 2003: Java 1.4.2 Prestanda, ännu fler GC, SSE, SSE2, ...2004: Java 1.5 Class data sharing, GC ergonomics2006: Java 1.6 Biased locking, lock coarsening, adaptive spinning, arraycopy, SSE4.2, large page heap

Historik: Prestanda

2006: Java 1.6 2007: u4: Hotspot får separat version, 10.02008: u10: Plugin2, GUI prestanda, kernel installer2009: u14: Hotspot 14, 1:a escape analysis, compressed object pointers, experimental G12009: u1x: Hotspot 15, SSE 4.2 string intrinsics2010 : u18: Hotspot 16,2010: u21: Hotspot 17,2011: u23: Hotspot 19, Escape analysis default enabled2011: u25: Hotspot 202011: u30:2011: Java 1.7 Hotspot 212011: u2: Hotspot 22

Förbättringar genom åren 1.2 1.3 1.4

Förbättringar genom åren 1.2 1.3 1.4

Förbättringar genom åren 1.4.2

Förbättringar genom åren 1.5

Förbättringar genom åren 1.5

Förbättringar genom åren 1.6

Förbättringar genom åren 1.5 1.6 1.7

http://geeknizer.com/java-7-whats-new-performance-benchmark-1-5-1-6-1-7/

Det längre svaret...

Några uppenbara:

● GC i separat(a) tråd(ar)● JIT kompilering i bakgrunden● Bättre utnyttjande av CPU, i386, i586,

Core2, ..., 32/64bit, SSE/1/2/4.2○ Ny JVM => bättre prestanda gratis

utan omkompilering● Fler intrinsics

Det längre svaret...

Bättre analys ger tex:

● Null check elimination, VM behöver göra: if (object == null) throw new NullPointerException()

● Array bounds check elimination 0>=i && i < array.length

● Hoist duplicates & repeated use int length = array.length; for (int i=0;i<array.length;i++) { if (array.length ...) {

Det längre svaret...

VM-lager inte bara nackdelar i prestanda:

● Pointers make optimizations hard x = y + 2 * (...) *p = ... arr[j] = ... z = x + ...

● Garbage Collection -> memory locality

● Runtime optimeringar○ CPU, P4, Sandy Bridge, SSE, cache sizes, cores, ...○ Current class hierarchy and inlining○ Branch predications

Det längre svaret...

Fler:● Generational Garbage Collector● Inlining● Spekulativa optimeringar● Förbättrade Garbage Collectors

○ Senaste: G1, "Garbage First" ● Tiered compilation (vs client/server)● Locks:

○ Lock elision○ Lock coarsining○ Adaptive locking○ Biased locks

● NUMA aware● Large pages (Solaris, Linux)● ...

Det längre svaret...

Några intressanta

● Virtual method inlining

● Escape Analysis (java 6u14, default enabled java7)

Så vad har vi nu då?Programspråket Java hör till kategorin "de snabba språken", tillsammans med Fortran och C/C++

~50-100% av C/C++ prestandaIbland snabbare! Quake2 vs Jake2 (Java5)

Men går utan problem att hitta fall där C++ är snabbare...

Escape AnalysisTex Dimension, Point, get/set, men inte begränsat till det...

http://weblogs.java.net/blog/forax/archive/2009/10/06/jdk7-do-escape-analysis-default

Escape Analysis

Escape Analysis

Off: ~430ms

On: ~110ms

Generational and Copying GC

Allokera en större bit Heap i förväg

Effektivisera per tråd med trådlokalt minne så ingen contention...

Generational and Copying GCGenerational:

● Young, Old (and Perm)

Young● De flesta objekt är kortlivade, 92-98%● Bevara (kopiera) bara de levande!

Minne:

Generational and Copying GCYoung

Generational and Copying GCYoung

Speculative virtual method inlining

Speculative virtual method inlining

Speculative virtual method inlining

February 2, 2004

Bill Venners: When I asked you earlier (In Part IV) about why non-virtual methods are the default in C#, one of your reasons was performance. You said:

We can observe that as people write code in Java, they forget to mark their methods final. Therefore, those methods are virtual. Because they're virtual, they don't perform as well. There's just performance overhead associated with being a virtual method.

Another thing that happens in the adaptive optimizing JVMs is they'll inline virtual method invocations, because a lot of times only one or two implementations are actually being used.

Anders Hejlsberg:They can never inline a virtual method invocation.

http://www.artima.com/intv/choices.html

Framtiden

● Tiered compilation default?● Disruptor pattern● Azul ZingVM -Cliff Click

○ Scalability○ 512GB heap○ Pauseless Garbage Collection

● Java 8○ Hotspot <-> JRockit○ Mer multicore i VM och API (ForkJoin med lambda tex)

● Java 9○ Self-tuning JVM○ Hypervisor integration○ Tail calls, continuations ○ "Massive multicore scalability"

References & Further reading

http://java.sun.com/j2se/1.4.2/performance.guide.htmlhttp://java.sun.com/j2se/1.4.2/1.4.2_whitepaper.htmlhttp://java.sun.com/performance/reference/whitepapers/5.0_performance.htmlhttp://java.sun.com/performance/reference/whitepapers/6_performance.htmlhttp://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html

http://www.ibm.com/developerworks/java/library/j-jtp09275/index.htmlhttp://www.ibm.com/developerworks/java/library/j-jtp10185/ http://www.ibm.com/developerworks/java/library/j-jtp12214/index.html

http://scribblethink.org/Computer/javaCbenchmark.html

Tack

Mattias Isegran Bergander

Feedback?mattias.bergander@gmail.com

profile.google.com/mattias.bergandertwitter.com/mbergandermattiaslife.blogspot.com