• J'aime
  • Télécharger
Garbage collection in JVM
Prochain SlideShare
Chargement dans... 5
×

Garbage collection in JVM

  • 7,338 vues
Transféré le

Practical overview of garbage collection in different JVMs with emphasis on tuning, large heaps and minimizing pause times ...

Practical overview of garbage collection in different JVMs with emphasis on tuning, large heaps and minimizing pause times
UPDATED 13 Oct 2011

Plus dans : Technologies , Éducation
  • Full Name Full Name Comment goes here.
    Êtes-vous sûr de vouloir
    Votre message apparaîtra ici
  • Hi
    i am new to GC
    can some help me on how to calculate application stopped time for the following JVM's
    1.JRocket
    2.IBM
    i did this for SUN by using -XX:+PrintGCApplicationStoppedTime
    but i didn't found any flag for above two JVM's
    or
    Any other way to calculate application stopped time
    Plz explain me
    Êtes-vous sûr de vouloir
    Votre message apparaîtra ici
  • Hi
    i am new to GC
    can some help me on how to calculate application stopped time for the following JVM's
    1.JRocket
    2.IBM
    i did this for SUN by using -XX:+PrintGCApplicationStoppedTime
    but i didn't found any flag for above two JVM's
    or
    Any other way to calculate application stopped time
    Plz explain me
    Êtes-vous sûr de vouloir
    Votre message apparaîtra ici
Aucun téléchargement

Vues

Total des vues
7,338
Sur Slideshare
0
À partir des ajouts
0
Nombre d'ajouts
2

Actions

Partages
Téléchargements
0
Commentaires
2
J'aime
29

Ajouts 0

No embeds

Signaler un contenu

Signalé comme inapproprié Signaler comme inapproprié
Signaler comme inapproprié

Indiquez la raison pour laquelle vous avez signalé cette présentation comme n'étant pas appropriée.

Annuler
    No notes for slide

Transcript

  • 1. Garbage collection in JVM and specifics of huge heaps Alexey Ragozin [email_address] Oct 2011
  • 2. OVERVIEW OF GARBAGE COLLECTION
  • 3. Garbage collection
    • Stop-the-world (STW) pause – pause of all application threads require
    • Compacting algorithms – can move objects in memory to defragment free space
    • Parallel collection – using multiple cores to reduce STW time
    • Concurrent collection – collection algorithms working in parallel with application threads
    Terms dictionary
  • 4. Garbage collection
    • Copy collection
      • Traverse object graph and copy reachable object to other space
      • Mark old space as free
    • Mark / Sweep
      • Traverse object graph and mark reachable objects
      • Scan (sweep) whole memory and “free” unmarked objects
    • Mark / Sweep / Compact
      • … mark … sweep ….
      • Relocate live objects to defragment free space
    Algorithms
  • 5. Garbage collection
    • S – whole heap size
    • L – size of live objects
    • Copy collection
    • Throughput
    • Mark / Sweep
    • Throughput
    • For all algorithms based on reference reachability. GC efficiency is in reverse proportion to amount of live objects .
    Economics
  • 6. Garbage collection Generational approach
  • 7. Garbage collection
    • Young space collection
      • High throughput
      • Low memory utilization
    • Promotion
      • Eden (nursery) -> Survivor (keep) space -> Old space
    • Old space collection
      • Better memory utilization
      • Orders of magnitude lower throughput
    • Memory barrier
        • JVM “tracks” references from old to young space
    Generational approach
  • 8. Oracle’s HotSpot JVM
    • Default (serial) collector
    • Young: Serial copy collector, Old: serial MSC
    • Parallel scavenge / Parallel old GC
    • Young: Parallel copy collector, Old: serial MSC or parallel MSC
    • Concurrent mark sweep (CMS)
    • Young: Serial or parallel copy collector, Old: concurrent mark sweep
    • G1 (garbage first)
    • Young: Copy collector (region based) Old: Incremental MSC
    http://aragozin.blogspot.com/2011/07/hotspot-jvm-garbage-collection-options.html
  • 9. Oracle’s HotSpot JVM
  • 10. Oracle’s JRockit JVM
    • Pick any flavor of mark/sweep/compact
    • Generational or single space
    • Young collection – parallel copy collector
    • Marking phase – parallel STW or concurrent
    • Compact phase – parallel STW or incremental (concurrent)
    http:// aragozin.blogspot.com/2011/07/jrockit-gc-in-action.html
  • 11. Oracle’s JRockit JVM http:// aragozin.blogspot.com/2011/07/jrockit-gc-in-action.html -Xgc: option Generational Mark Sweep/Compact genconcon or gencon Yes concurrent incremental singleconcon or singlecon No concurrent incremental genconpar Yes concurrent parallel singleconpar No concurrent parallel genparpar or genpar Yes parallel parallel singleparpar or singlepar No parallel parallel genparcon Yes parallel incremental singleparcon No parallel incremental
  • 12. IBM’s J9
    • -Xgcpolicy:optthruput
    • Single space, stop-the-world collector
    • -Xgcpolicy:optavgpause
    • Single space, partially concurrent collector
    • -Xgcpolicy:gencon
    • Generational, partially concurrent collector
  • 13. Azul’s Zing JVM
    • Generational collection
    • Young space – concurrent MSC
    • Old space – concurrent MSC
    • Unlike competitors, Azul can do compaction without STW pause.
    • Secret is using of read barrier.
  • 14. YOUNG COLLECTION
  • 15. Tuning CMS for low pauses
    • Memory geometry
    • Young space: -XX:NewSize=<n> -XX:MaxNewSize=<n>
    • Survival space: Young space / -XX:SurvivorRatio=<n>
    • Young + old space: -Xms<n> -Xmx<n>
    • Permanent space: -XX:PermSize=<n> -XX:MaxPerSize=<n>
    Memory in HotSpot JVM
  • 16. How young collection works?
    • Collect root references
      • Stack frame references
      • References from other spaces (tenured + permanent)
    • Travers object graph
      • Visit only live object
      • Copy live object to other region of young space or old space
    • Consider whole Eden and old survivor space to be free memory
    • Write barrier is required to effectively collect references from old to young space.
  • 17. How young collector works Collecting root references
  • 18. How young collection works? Coping live objects
  • 19. How young collection works? Collection finished
  • 20. Card marking write barrier
  • 21. Thread local allocation blocks
    • Each thread preallocates block in Eden
    • Thread is allocating new objects in its TLAB
    • Then TLAB is full, new TLAB allocated
    • If object does not fit TLAB
      • Allocate in Eden space
        • If does not fit Eden (or ‑XX:PretenureSizeThreshold )
          • Allocate in old space
  • 22. Young collection stop-the-world
    • Total STW time
      • Collect roots
        • Scan thread stacks
        • Scan dirty cards
          • Read card table ~ S heap
          • Scan pages marked as dirty ~
      • Copy live objects
      • Process special references
    * You can use -XX:+PrintGCTaskTimeStamps to analyze time of individual phases * You can use -XX:+PrintReferenceGC to analyze reference processing times
  • 23. Tuning young collection
    • Eden size
    • too small – frequent YGC, objects promoted to old space early
    • too large – more long lived objects need to be copied
    • Survivor space size
    • too small – overflow, objects prematurely promoted
    • too large – memory wasted
    • Tenuring threshold
    • higher – objects are kept in young space for longer
    • higher – more objects in young space, more copy time
  • 24. Tuning young collection
    • Eden size
    • -XX:MaxNewSize=<n> -XX:NewSize=<n>
    • Eden size = new size – 2 * survivor space size
    • Survivor space size
    • -XX:SurvivorRatio=<n>
    • Survivor space size = new size / survivor ratio
    • Tenuring threshold
    • -XX:MaxTenuringThreshold=<n>
  • 25. Tuning young collection
    • Small heap sizes
    • Balance tenuring threshold / survivor space to keep objects in limited young space for longer
    • Large heap sizes (4Gb and greater)
    • Limit tenuring threshold to avoid increase in copy time
    • Limit survivor space to avoid accidental long young collections
    • Increase Eden size instead of increasing tenuring threshold
  • 26. Tuning young collection Research mode
  • 27. Tuning young collection
    • GC tuning is based on application allocation pattern
    • If application allocation patterns is changed – you are in trouble
    • In practice application always have different “modes of operation”
    • GC tuning – choosing better evil
  • 28. OLD SPACE COLLECTION
  • 29. Old space collection
    • HotSpot
    • Parallel
    • Concurrent Mark Sweep (CMS)
    • G1
    • JRockit
    • Parallel
    • Incremental (concurrent)
  • 30. Old space collection
    • HotSpot’s G1
    • Space is divided into regions
    • Regions can be collected individually
    • Write barrier between regions
    • JRockit’s concurrent (increamental)
    • Space is divided into regions
    • Mark/Sweep whole heap, compact just a fraction
  • 31. Old space collection
    • HotSpot’s CMS (Concurrent Mark Sweep)
    • Does not compact
    • Prone to fragmentation
    • Use separate free lists for each object size
    • Use statistic to manage fragmentation
  • 32. Tuning CMS for low pauses
    • Young collection STW pause
    • Initial marking STW pause
    • Remark STW pause
    • Promotion failure / Full GC pause
    Summary of pauses
  • 33. Cost structure of pauses (CMS) Summary of pauses
  • 34. Patching OpenJDK Vicious loop http://aragozin.blogspot.com/2011/07/openjdk-patch-cutting-down-gc-pause.html void ClearNoncleanCardWrapper :: do_MemRegion ( MemRegion mr ) { … while ( cur_entry >= limit ) { HeapWord * cur_hw = _ct -> addr_for ( cur_entry ); if ((* cur_entry != CardTableRS :: clean_card_val ()) && clear_card ( cur_entry )) { // Continue the dirty range by opening the // dirty window one card to the left. start_of_non_clean = cur_hw ; } else { // We hit a &quot;clean&quot; card; process any non-empty // &quot;dirty&quot; range accumulated so far. if ( start_of_non_clean < end_of_non_clean ) { const MemRegion mrd ( start_of_non_clean , end_of_non_clean ); _dirty_card_closure -> do_MemRegion ( mrd ); } // Reset the dirty window, while continuing to look // for the next dirty card that will start a // new dirty window. end_of_non_clean = cur_hw ; start_of_non_clean = cur_hw ; } cur_entry --; } … }
  • 35. Patching OpenJDK Vicious loop - Optimized void ClearNoncleanCardWrapper :: do_MemRegion ( MemRegion mr ) { ... while ( cur_entry >= limit ) { HeapWord * cur_hw = _ct -> addr_for ( cur_entry ); if ((* cur_entry != CardTableRS :: clean_card_val ()) && clear_card ( cur_entry )) { start_of_non_clean = cur_hw ; cur_entry --; } else { if ( start_of_non_clean < end_of_non_clean ) { const MemRegion mrd ( start_of_non_clean , end_of_non_clean ); _dirty_card_closure -> do_MemRegion ( mrd ); } // fast forward via continuous range of clean cards // hardcoded 64 bit version if (((( jlong ) cur_entry ) & 7 ) == 0 ) { jbyte * cur_row = cur_entry - 8 ; while ( cur_row >= limit ) { if (*(( jlong *) cur_row ) == (( jlong )- 1 ) /* hardcoded row of 8 clean cards */ ) { cur_row -= 8 ; } else { break ; } } cur_entry = cur_row + 7 ; HeapWord * last_hw = _ct -> addr_for ( cur_row + 8 ); end_of_non_clean = last_hw ; start_of_non_clean = last_hw ; } else { end_of_non_clean = cur_hw ; start_of_non_clean = cur_hw ; cur_entry --; } } ...
  • 36. Patching OpenJDK Serial collector gain http://aragozin.blogspot.com/2011/07/openjdk-patch-cutting-down-gc-pause.html
  • 37. Patching OpenJDK CMS collector gain http://aragozin.blogspot.com/2011/07/openjdk-patch-cutting-down-gc-pause.html
  • 38. CMS, PLABs and fragmentation
  • 39. CMS, PLABs and fragmentation
  • 40. CMS, PLABs and fragmentation
  • 41. CMS, PLABs and fragmentation
  • 42. JRockit’s gencon Hidden pauses
  • 43. Tuning old space
    • -Xms<N> -Xmx<N>
    • Young space is not for object, it is for garbage
    • If you old space is 100% full, GC throughput is zero
    • CMS: 50%-20% head room for GC
    • JRockit’s gencon / HotSpot’s G1: 50%-70% head room
    • Exploiting multiple cores (HotSpot JVM)
      • -XX:+CMSConcurrentMTEnabled
      • -XX:ParallelGCThreads=<n>
      • -XX:ConcGCThreads=<n>
  • 44. OTHER ASPECTS OF GC IN JAVA
  • 45. JNI and pinning objects
    • Normally JNI code is working with copy of java object.
    • Native code my request direct pointer to java heap.
    • GetPrimitiveArrayCritical/ReleasePrimitiveArrayCritical
    • GetStringCritical/ReleaseStringCritical
    • While object is pinned, JVM cannot relocate it in heap.
    • Diagnostics
    • -XX:+PrintJNIGCStalls
  • 46. Finalizers
    • JVM have to keep special reference for object eligible for finalization
    • Object with finalizers survive at least one more GC cycle
    • Finalizer is called only then object is found unreachable during GC, GC of old space could be very rare
    • Use reference queues instead of finalizers
  • 47. Soft references
    • In server mode, JVM cleans soft reference if it was not dereferenced during N milliseconds. N is proportional to amount of free heap space after last old space GC.
    • -XX:SoftRefLRUPolicyMSPerMB=<N>
    • LRU policy relies on usage of reference get() method, not access to referenced object.
  • 48. SURVIVING HUGE HEAP CONCLUSION
  • 49. GC tuning summary
    • Young space tuning
    • Find balance between, pause frequency, pause time (time to copy objects) and object promotion age
    • Old space tuning
    • Ensure throughput by providing enough head room for garbage
  • 50. Surviving with huge heap
    • CMS is very good in terms of pauses
      • You can reliably keep pauses under 150ms – 50ms on 30GiB – 50 GiB
    • Fragmentation treat
      • Not big deal for server type of applications
      • XML processing is GC disaster
    • Very narrow GC comfort zone
      • If you tune for “long run” you are likely to have pauses during initial loads / bulk refreshes
  • 51. MOVING OUT OF HEAP
  • 52. Direct memory buffers
    • java.nio.ByteBuffer.allocateDirect()
    • Pro
    • Memory is allocated out of heap
    • Memory is deallocated when ByteBuffer is collected
    • Cross platform, native java
    • Con
    • Fragmentation of non-heap memory
    • Memory is deallocated when ByteBuffer is collected
    • Complicated multi thread programming
    • -XX:MaxDirectMemorySize=<value>
  • 53. RTSJ
    • Scoped memory
    • Objects can be allocated in chosen memory areas
    • Scoped and immortal areas are not garbage collected
    • Scoped areas can be release by whole area
    • Cross references between areas are limited and this limitation is enforced in run time
  • 54. Unsafe java
    • sun.misc.Unsafe
    • Unsafe.allocateMemory(…)
    • Unsafe.reallocateMemory(…)
    • Unsafe.freeMemory(…)
  • 55.
    • Thank you
    Alexey Ragozin [email_address] http://aragozin.blogspot.com - my articles