Sun Microsystems, Inc. simon.roberts@sun - Software Summit

Colorado Software Summit: October 26 – 31, 2003 © Copyright 2003, Sun Microsystems, Inc.

Simon Roberts — Performance

PerformanceSimon RobertsSun Microsystems, [email protected]

mailto:[email protected]



No Easy/Universal AnswersBalance performance/scalability against reliability, usability, maintainability, reusability, portabilityIdeas to keep in mind, questions to ask, not answers



What Is “Performance?”Speed

transaction timetransactions per second

Perceived responseStartup timeReaction timeVisible progress• Time spent updating progress bar

Memory use



Need for ProfilingMeasure, don’t guessMeasure in realistic conditions

Beware of JIT effects

Don’t optimize before you measure



Memory UseObjects

Heap

ClassesPermanent generation

Thread stacksFixed size (typically 1/4 to 1MB, -Xss changes)Method localsNative heap

Native elements



Observing Memory Usehprof, third party tools-verbose:gc / -XPrintGC-XX:+PrintHeapAtGC

Details of memory areas before and after each collection



Garbage Collector EffectsGC increases reliabilityGC reduces performance



Pauses and ThroughputGC takes time/CPU powerGC is lazy

Objects aren’t cleaned immediatelyMemory demand increases

GC is normally single threaded & critical“Stop the world” pauses-Xincgc (train)



Improving GCTypical object life profile:

Many short-lived, some long-livedNot much in between

Clean up young objects more oftenFewer objects to checkHigher “success” ratio

Partition off old/long-livedCalled “generational” garbage collection



Improving GC (2)VM is efficient with this life distributionDon’t pool without a strong reason

Management of pool often negates small benefit Objects that are expensive to create should be pooledConsider returning primitives, or immutable-type references from accessor methods



Simple CopyingCompaction housekeeping is onerousCopying is much more efficient on CPU

But more demanding on memory



Smarter Copying – 1



Minor CollectionsCopy Eden + 1 survivor to other survivorOverflow directly to tenured space

Generally bad

Young generation guaranteeTenured must have enough for all youngIf not, you must perform full collection



J2SE Platform 1.4.2 Heap DesignTwo (plus one) regions

Young–copying collectorTenured–compacting collectorPermanent

Young consists of:EdenTwo survivor spaces



GC & ParallelismSingle threaded GC impacts system throughput, particularly on multi-CPU hardware

Need for alternate collectorsParallel collection causes fragmentation• Needs more memory



Throughput Collector:Collects young generation with multiple threads-XX:+UseParallelGC-XX:+AggresiveHeap

Larger memory (>= 256 Mbytes)



Concurrent (1.4.2 on)Collects tenured generation concurrently-XX:+UseConcMarkSweepGC

Pauses for initial mark and re-mark-XX:+UseParNewGC



Server Memory ConsiderationsStart with big-enough heap, don’t let server systems resize-Xmx-Xms-XX:MinHeapFreeRatio-XX:MaxHeapFreeRatio

Don’t let VM pageISM/MPSS



Miscellaneous GC IssuesUsing references rather than finalization

Finalization keeps objects around longer Both are non-deterministic

Avoid use of System.gc()Might do nothingMight behave extremelyMight negate optimizations



Class UnloadingCannot be automaticCreate class loader instanceLoad classesAll classes collected when:

All instances of all loaded classes are collectableClass loader instance itself is collectable

-XX:MaxPermSize=<???>



Class LoadingDelayed loading/lazy instantiation

Empty/minimal startup program, especially appletVerifier loads referenced classesMyInterface mi=(MyInterface)(Class.forName(stringVar).newInstance());

Fewer classesClasses take memory in VM to load, more than the code size suggests (~3K)



Class LoadingPerceived performance impactMinimizing class/jar file size

debug info javac -g:noneclass/method/member names (obfuscators)

Jar files, especially over networksBut must load entire jar before startup

WebStart



StringsUse StringBuffer for manipulation

+, concat, replace, substring, trim

Avoids creating intermediate objects

String.intern()Might save memoryAllows comparison with == vs.equalsBut watch the permanent generation size



ReflectionExpensiveHard to compile/optimize (20 times slower on stabilized hot-spotTry to use interfaces instead



Thread IssuesSynchronization

Keep to a correct minimum

DeadlockVector and HashTable

All methods synchronizedDon’t really protect anyway (read, modify, write is potentially non-atomic)

BTW, Deadlock detector



Thread ModelsSolaris libraries & thread models-XX:+UseTLE (1.3), -XX:+UseTLAB (1.4)

For programs using hundreds of threads



Hotspot JITClient & server priorities

Memory use, unloadingStartupCPU investment

Compiled methods aren’t storedLess helpful with

Allocation & GCSynchronizationLow memory systems



JIT BehaviorCompiles whole methods

Called frequentlyLong lived (OSR)Including native wrappersInlines some methods (e.g. trivial accessor/mutator)• At runtime, allowing checks for overriding

Can re-optimize as new classes load



Profiling with JITMicro-profiling is unreliableDead-code, loop invariant, common sub-expressions, constants, null and range check elimination



Watching & Controlling HotSpot-XX:+PrintCompilation

Disable compilation via file.hotspot_compiler

In current directoryContaining, e.g.exclude java/lang/String indexOf



RMI/Distributed SystemsSocketsCORBA, struct-likeRMI

True objects, state and behaviorEmbed different behavior behind same interfaceCaching, read-ahead, granularity control can change with experienceDGC lease renewals



SerializationWrites field names etc.Transitive closure

Watch out for irrelevant stuff

use of transient, private readObject/writeObject

in.defaultReadObject()

Memory leaks if streams not closed



GraphicsClipping, compare:

Cost to calculate clipCost to determine if in/out of clipCost to calculate pixel valueCost to render pixel

Buffering to avoid recalculationPixmap location (X-server vs. X-client) in Java2DBatched updates



MiscellaneousWatch for copies of mutable objects returned from methods

e.g. Dimension object from Graphics.getSize()

Use System.arraycopy()Inner classes accessing variables of enclosing scopes



MiscellaneousDo IO in large chunks

Buffered, NIO

Condition tests are much cheaper than throwCan spoil optimizations

Sun Microsystems, Inc. simon.roberts@sun - Software Summit

Documents

Transcript of Sun Microsystems, Inc. simon.roberts@sun - Software Summit