© 2005 azul systems, inc. | confidential java™ performance myths exposed gil tene, vp technology,...

© 2005 Azul Systems, Inc. | Confidential

Java™ Performance Myths Exposed

Gil Tene, VP Technology, CTO

Ivan Posva, Senior Staff Engineer

Azul systems

2

www.azulsystems.com

©2005 Azul Systems, Inc. Strictly Confidential. Do not distribute or share any of this information without specific approval from Azul Systems.

Learn about some performance tips that are now irrelevant

Avoid premature optimizations

Write portably performant Java code

(… and what has changed in two years)

Writing Fast Java Code

3

www.azulsystems.com


Compare 7 JVMs against

6 Performance Hacks

4

www.azulsystems.com


The JVMs

• 3.2GHz 2-way Xeon w/hyperthreading, Linux 2.6:─ BEA “Jrockit” 5.0─ IBM “Sovereign” 1.4.2─ Sun “HotSpot” -server 1.4.2_06─ Sun “HotSpot” -server 5.0

• 1.2GHz 2-way UltraSPARC III, Solaris 9:─ Sun “HotSpot” -server 1.4.2_06─ Sun “HotSpot” -server 5.0

• Azul 96-way Vega, launched from Linux 2.6:─ Azul “HotSpot” -server 1.4.2_06

5

www.azulsystems.com


The Performance Myths

• Using exceptions to exit loops

• Use “final” everywhere

• Avoid try/catch blocks

• Use RTTI to avoid virtual calls

• Avoid synchronization

• Object Pooling

• New 5.0 features are free

6

www.azulsystems.com


Comparing Performance Myths

• Will present alternate coding styles─ Clean code vs─ Performance-hacked code

• Time both on 7 JVMs

• Looking for relative, not absolute, performance

• No one JVM wins all speedup benchmarks─ JVMs have different strengths and weaknesses

• Performance vs maintenance tradeoff

7

www.azulsystems.com


Use Final Everywhere

• Myth 1: Use “final” everywhere

• Idea: Allow more inlining

• Reality: Inlining (mostly) happens without it

final

public int get() { return fld; } public void set(int x) { fld=x; }no final

public final class Test { public int get() { return fld; }final class

final child public final class Test2 extends Base {

public final int get() { return fld; } public final void set(int x) { fld=x; }

8

www.azulsystems.com


Use Final Everywhere

smaller is faster

9

www.azulsystems.com


Try/Catch Blocks are Free (or Not)

• Myth 2: Try/catch blocks are free(or very expensive)

• Reality is more complex─ Defeats bounds-check opts on some JVMs─ Free otherwise

try/catch

for( int i=0; i < A.length; i++ ) sum += A[i];vectorsum

for( int i=0; i < A.length; i++ ) try { sum += A[i]; } catch( Error e ){}

NPE catch( NullPointerException e ) {}

10

www.azulsystems.com


Try/Catch is Not Free

Array Intensive

11

www.azulsystems.com


Try/Catch Blocks are Free (or Not)

• Myth 2': Try/catch blocks are free(or very expensive)

try/catch

Integer keys[100], vals[100]; for 100 times... for all keys, vals...

HASH.put(keys[i],vals[i]); for all keys... sum += f(HASH.get(keys[i])));

Hashtable

for 100 times... try { for all keys, vals...

HASH.put(keys[i],vals[i]); } catch( Error e ){}

NPE } catch( NullPointerException e ) {}

12

www.azulsystems.com


Try/Catch is (Mostly) Free

Hashtable Intensive

13

www.azulsystems.com


RTTI vs instance-of vs v-call

• Myth 3: Use Run-Time Type Info─ Replace v-call with instance-of if-tree─ Or faster switch statement

abstract class Base { abstract void v_call(); ... v_call(); // dynamic dispatch here ... } class Child1 extends Base { void v_call() { /* Child1-specific */ } } class Child2 extends Base { void v_call() { /* Child2-specific */ } }

14

www.azulsystems.com



• Myth 3: Use Run-Time Type Info─ Replace v-call with instance-of if-tree

abstract class Base { ... if( this instanceof Child1 ) ((Child1)this).non_v_call(); // JVM can inline else if( this instanceof Child2 ) ((Child2)this).non_v_call(); // JVM can inline else ... } class Child1 extends Base { void non_v_call() { /*Child1-specific*/ } } class Child2 extends Base { void non_v_call() { /*Child2-specific*/ } }

15

www.azulsystems.com



• Myth 3: Use Run-Time Type Info─ int per object, passed into Base constructor─ Turns OO Java code into C code

abstract class Base { final int _rtti; Base( int r ) { _rtti=r; } ... ... } class Child1 extends Base { Child1() { super(1); } } class Child2 extends Base { Child2() { super(2); } }

16

www.azulsystems.com



• Myth 3: Use Run-Time Type Info─ Use switch statement─ Hand inline child bodies

abstract class Base { final int _rtti; Base( int r ) { _rtti=r; } ... switch( _rtti ) { case 1: // hand-inline Child1 specifics case 2: // hand-inline Child2 specifics ... }

17

www.azulsystems.com



• Myth 3: Use Run-Time Type Info─ Replace v-call with instance-of if-tree─ Or faster switch statement

• But code gets really ugly─ Instances have more footprint, too

i-of

v_call(); // dynamic dispatch herevcall

if( this instanceof Child1 ) ((Child1)this).non_v_call();

rtti switch( _rtti ) { case 1: // hand-inline Child1 specifics

18

www.azulsystems.com



19

www.azulsystems.com


Avoid Synchronization

• Myth 4: Synchronization is expensive

• Reality: 55-110 nanos for uncontended lock+unlock, on a dual 3.2GHz Xeon

─ Not free, but not terribly expensive─ Intel x86 MP (>2-way DP): cost is higher

• Race-condition bugs are devilishly hard to find, fix and debug

• A little over-synchronization is not fatal

• If you see heavy contention:─ Maybe need a different algorithm─ Gratis plug for 5.0 concurrency libraries goes here

20

www.azulsystems.com


Raw uncontended sync cost

21

www.azulsystems.com


Lightly contended (0.1%)

22

www.azulsystems.com


Object Pools: new vs reuse

• Myth 5: Reuse objects instead of new + GC─ Requires synchronized free list (scaling bugs)─ Explicit “free” operation (leaking, dangling ptr bugs)─ Object must be reset

• Usefulness varies by cost to initialize object & frequency of allocation

reuse

t = new Hashtable(); // delete is a no-op; GC gets it

new+GC

t = Hashtable.make(); // factory ... Hashtable.free(t); // explicit del

23

www.azulsystems.com


Object Pools: New vs Reuse

24

www.azulsystems.com


Object Pools Summary

• Loss for light-weight objects

• Now a loss for mid-weight objects (Hashtables)

• Some VMs: Still a win for heavy-weight objects (JPanel)─ (but with maintenance costs and scalability problems)

25

www.azulsystems.com


Cost of new 5.0 features

• Myth 6 (A): Cost of foreach, autoboxing, varargs?

• Supposed to be syntactic sugar, “free”

foreach

for( int i=0; i<Rank.VALUES.length; i++ ){ switch( Rank.VALUES[i] ) { case DEUCE: ...

for

for( Rank i : Rank.VALUES ) { switch( i ) { case DEUCE: ...

auto box

Integer I = Integer.valueOf(i); sum += I.intValue();hand box

Integer I = i; sum += I;

26

www.azulsystems.com


Cost of foreach, autoboxing, varags

27

www.azulsystems.com


Cost of new 5.0 enums

• Myth 6 (B): Cost of new enum feature?

• Supposed to be syntactic sugar, “free”

final obj

static final int DEUCE = 0; ... static final int ACE = 12; for( int i=0; i<MAX_RANK; i++ ) if( i == DEUCE ) ...

final int

static final Rank DEUCE = new Rank(0); for( int i=0; i<MAX_RANK; i++ ) Rank r = Rank.values[i]; if( r == DEUCE ) ...

enum public enum Rank { DEUCE, ... for( Rank i : Rank.values() ) { if( i == DEUCE ) ...

28

www.azulsystems.com



29

www.azulsystems.com



• What happened?

• Rank.values():

return (Rank[])VALUES.clone();

• Hoist call to values() up higher:

30

www.azulsystems.com


Summary

• “final” does not help performance

• try/catch blocks are free─ (except in tight inner loops)

• RTTI is a marginal performance win with a very high maintenance cost

• Synchronization is cheaper than bugs─ (and multi-cores are here!)

• GC works: Use Object Pools sparingly, or not at all

• New 5.0 features are nearly free─ (except for enum “values” call)

31

www.azulsystems.com


Looking Backward, Looking Forward

• GC got cheaper─ Parallel GCs now available in all these JVMs─ GC efficiency fairly high─ CPU spent on GC generally cheaper than avoiding it

• GC will become less intrusive─ Somewhat Concurrent GCs now available in all these JVMs─ May trade off throughput for concurrency─ Can be very sensitive, mutators can outrun collector

• GC Scaling─ Large heaps (> 4Gig) & Pause times still an issue

• GC challenges: JVMs have different strategies

32

www.azulsystems.com



• Object Pooling will remain viable only for high (and external) init costs

• Escape Analysis:─ Small local objects are cheaper─ In some of these JVMs for sure─ Likely coming in the others “soon”

• 5.0 features mostly perform well

• Enums values() call - oops?─ Suspect this will get fixed by the next release

33

www.azulsystems.com



• Synchronization is getting cheaper─ Basic lock idiom is cheap

─ Dozen cycles on single CPU system

─ Some JITs doing some lock optimizations

─ More JIT lock optimizations coming

─ New JDK 5.0 Containers much cheaper, scale better

e.g. ArrayList, HashMap

34

www.azulsystems.com



• Synchronization is getting expensive─ Basic x86 CAS op more expensive on Intel multi-cores

─ 200+ cycles per CAS─ Multi-core is now common, so…─ More code running on multi-cores, so…─ More thread to use the more cores, so…─ More data-race bugs found, fixed by adding…─ More synchronization keywords

• Synchronization, contention, and scaling will remain an issue

35

www.azulsystems.com


If you remember only one thing…

Modern JVMs favorclean usage patterns and

clean code

36

www.azulsystems.com


Our Layers made us say this…

"Azul Systems, Azul, and the Azul arch logo are trademarks of AzulSystems, Inc. in the United States and other countries. Sun, SunMicrosystems, Java and all Java based trademarks and logos aretrademarks or registered trademarks of Sun Microsystems, Inc. in theUnited States and other countries. Other marks are the property of theirrespective owners and are used here only for identification purposes."


Q & A


Thank you.

[email protected]

[email protected]

© 2005 azul systems, inc. | confidential java™ performance myths exposed gil tene, vp technology,...

Documents

azul systems

azul hotspot server

use final

specific approval

final public int

public final int

final public final class

free slide