Managed Runtime Systems: Lecture 04 - Memory Management (Continued)

Transcript

Managed Runtime Systems Lecture 04: Memory Management (Continued) Foivos Zakkak

https://foivos.zakkak.net Except where otherwise noted, this presentation is licensed under the Creative Commons Attribution 4.0 International License. Third party marks and brands are the property of their respective holders.

Acknowledgments The following slides are based on the corresponding slides

of Mario Walczko about Memory Management: Memory management part 1 Memory management part 2 Memory management debugging hints Managed Runtime Systems 1 of 13 https://foivos.zakkak.net

The Tri-color Abstraction Color each object depending on its current

state Initially all objects are white (non processed) Each time an object gets traced it gets colored gray After an object has been scanned it gets colored black Managed Runtime Systems 2 of 13 https://foivos.zakkak.net

Tri-Color Tracing roots A B C D E F G

H A H F A D G H F E D E G Managed Runtime Systems 3 of 13 https://foivos.zakkak.net

Tri-Color Tracing roots A B C D E F G

Copying Tri-color roots From To To From A B C

D C B D C B D Managed Runtime Systems 4 of 13 https://foivos.zakkak.net

Copying Tri-color roots From To To From A B C

Main Advantage of the Tri-Color Abstraction Allows for incremental garbage

collections Reduce the length of stop-the-world pauses Mutator threads and GC-scanning threads can run concurrently More on incremental and concurrent GCs on future lectures! Managed Runtime Systems 5 of 13 https://foivos.zakkak.net

Main Drawback of Semi-space Collectors They require twice the memory!!!

Managed Runtime Systems 6 of 13 https://foivos.zakkak.net

Main Drawback of Semi-space Collectors They require twice the memory!!!

and They copy long-lived data all the time!!! Managed Runtime Systems 6 of 13 https://foivos.zakkak.net

The Generatinal Hypothesis Most objects die young! Managed Runtime Systems

7 of 13 https://foivos.zakkak.net

The Generatinal Hypothesis Most objects die young! What if we

could collect young objects separately? Managed Runtime Systems 7 of 13 https://foivos.zakkak.net

Generational Collectors Further slice the heap in generations (usually eden,

young, and old) Move surviving objects to older generation (called tenuring) Occasionally perform a full mark-and-sweep collection Managed Runtime Systems 8 of 13 https://foivos.zakkak.net

Generational Collectors Eden Young Old A B C D E

F G H D F I J K L M D K D K L Managed Runtime Systems 9 of 13 https://foivos.zakkak.net

Generational Collectors Eden Young Old A B C D E

Keeping Track of Old to Young References Avoid scanning old

generation at young collections Keep a set of old-to-young references (called remembered set) Monitor writes to reference fields of old objects (called write-barrier) Managed Runtime Systems 10 of 13 https://foivos.zakkak.net

Card Marking write-barriers Keep a bit per memory block of

old generation The bit indicates whether objects in the block reference young objects The card gets reset in every collection Managed Runtime Systems 11 of 13 https://foivos.zakkak.net

Generational Collection in Action 2 4 6 8 10 12

14 16 18 20 Perm Gen Old Gen New Gen Code Others VM Fig. 4: javac D- & E-cache contents, and heap usage 0 2 4 6 8 10 12 14 16 18 20 22 0 0.1 0.2 0.3 0.4 Cache 0 2 4 6 8 10 12 14 16 18 20 22 0 2 4 6 8 10 12 14 16 18 20 22 Cycles (billions) Heap Usage (MB) Fig. 7 Table 1 Fig. 8 E Figure Source: Introspection of a Java Virtual Machine under Simulation, Wright et al, Sun Labs TR-2006-159 Managed Runtime Systems 12 of 13 https://foivos.zakkak.net

Tuning Generational Garbage Collectors Tenuring threshold Allocating directly to old

space Size of generations Old space collectors Managed Runtime Systems 13 of 13 https://foivos.zakkak.net

Managed Runtime Systems: Lecture 04 - Memory Ma...

Managed Runtime Systems: Lecture 04 - Memory Management (Continued)

More Decks by zakkak

Other Decks in Programming

Featured

Transcript