Heap Area

Tanım: JVM'de çalışma zamanı (runtime) sırasında yaratılan tüm nesnelerin tutulduğu memory alanı. Tüm thread'ler bu alana erişebilir ve thread safe değildir. Heap alanı dolduğu Garbage Collector bellekte temizlik yaparak yer açar. Heap boyutu –Xms1G -Xmx4G şeklinde min ve max verilerek ayarlanabilir.

---

Stack Area

Tanım: JVM'de bir Thread'e ait bir method çalıştırılması sırasında method içindeki primitive tip (int, boolean, float vb..) değerleri ile method içinde kullanılan ve Heap Area'da tutulan nesnelere olan referansları saklar. Method çalıştırılması sona erince yaratılan yığın (stack) Stace Area'dan kaldırılır. Eğer recursive method'larda yanlışlıkla sonsuz döngüye girilirse veriler aynı stack'e yazmaya devam edeceğinden StackOverflowError hatası oluşur. Stack alanının boyutu -Xss parametresi ile verilebilir.

---

Runtime Data Area - Çalışma Zamanı Data Alanı

Tanım: JVM 'nin kullanıdığı ve yönettiği memory (hafıza) alanları. Bu alanlar Method Area, Heap Area, Stack Area, PC(Program Counter) Registers, Native Method Stacks alanlarıdır.

---

Method Area - Metaspace

Tanım: JVM'de derlenmiş kodlar, sınıf bilgileri, değişkenler, sabitler ve methodlar hakkında meta bilgilerin tutulduğu hafıza alanı. Eski adı Permanent Generation (PermGen) şeklinde idi. PermGen de alan sabit iken Metaspace'de dinamik olabilmektedir.

---

Native Method Stacks

Tanım: JVM'de bir uygulama Java kodu dışında yerel kod blokları (native kod) çalıştırdığında Java Stack Area benzeri tuttuğu hafıza alanı.

---

Program Counter Registers

Tanım: JVM'de bir Thread için hangi komutun çalıştırılacağını tespit etmek için en son hangi method'u çalıştırdığını kaydettiği hafıza alanı. Her thread için ayrı bir PC Resgiter vardır.

---

Garbage Collection - Çöp Toplama

Tanım: Bir yazılımın çalışması sırasında bellekte nesnelerin otomatik olarak yaratılması, saklanması ve kaldırılması işlemlere verilen isim. Çöp Toplama işini yapan birimlere Garbage Collector - Çöp Toplayıcı adı verilmektedir

---

Garbage Collector - Çöp Toplayıcı

Tanım: Bir yazılımın çalışması sırasında bellekte nesnelerin otomatik olarak yaratılması, saklanması ve kaldırılması işlemlerini yöneten birim

---

Young Generation - New Generation

Tanım: Java'da Garbage Collection sisteminde yeni yaratılmış nesneler ve onların saklandığı bölüm. Belirli bir süredir kullanılmayan (eski) nesneler ise Old Generation bölümünde tutulmaktadırlar

---

Old Generation - Tenured Generation

Tanım: Java'da Garbage Collection sisteminde belirli bir süredir kullanılmayan (eski) nesneler ve onların saklandığı bölüm. Yeni nesneler ise Young Generation bölümünde tutulmaktadırlar

---

Permanent Generation - Metaspace

Tanım: Java'da Garbage Collection sisteminde JVM'nin kendisi için kullandığı(uygulama içinde yaratılan nesnelerin değil) hafıza bölümü

---

Eden

Tanım: Java'da Garbage Collection sisteminde , Java'da ilk yaratılan nesnelerin saklandığı bölüm. Eden bölümü Young Generation içindedir

---

Survivor

Tanım: Java'da Garbage Collection sisteminde , Java'da ilk yaratılan nesnelerin saklandığı Eden bölümünde yaşamaya devam eden nesnelerin alındığı bölüm. Survivor bölümleri Young Generation içinde bir bölümdür

---

Serial GC

Tanım: Java'da garbage collection (çöp toplama) işini tek bir thread ile yapan garbage collection algoritması. Bir uygulama çalıştırılırken -XX:+UseSerialGC şeklinde option (seçenek) verilerek kullanılabilmektedir. Serial GC aynı anda tek thread çalışabilir, aynı anda birden fazla thread çalışan GC sistemine ise Parallel GC adı verilmektedir

---

Parallel GC - Throughput GC

Tanım: Java'da garbage collection (çöp toplama) işini tek bir thread ile yapan garbage collection algoritması. Bir uygulama çalıştırılırken -XX:+UseParallelGC ve XX=+UseParallelOldGC şeklinde option (seçenek) verilerek kullanılabilmektedir. GC toplama işini çok sayıda thread yapmasından dolayı Serial Garbage Collector'e göre hızlıdır.

---

Concurrent Mark-Sweep GC - CMS GC - Concurrent Low Pause GC

Tanım: Java'da garbage collection (çöp toplama) işini farklı sayıda thread kullanarak, daha hızlı çöp toplama yapan GC algoritması. Bir uygulamada -XX:+UseConcMarkSweepGC şeklinde option (seçenek) verilerek kullanılabilmektedir. Bu sistem Parallel GC'ye gibi çok thread'le çalışmaktadır. Bu nedenle bekleme zamanı çok daha kısadır ve daha hızlı çalışmaktadır

---

G1 GC - G1GC - Garbage First Garbage Collector

Tanım: JDK 7 update 4 versiyonundan sonra desteklenen Java HotSpot Garbage Collection sistemi. Bir uygulama çalıştırılırken -XX:+UseG1GC şeklinde option (seçenek) verilerek kullanılabilmektedir

---

-XX:+UseSerialGC

Tanım: Java'da Serial GC (Garbage Collector) kullanımı için eklenen jvm seçeneği (option)

---

-XX:+UseParallelGC

Tanım: Java'da Young Generation alanında Parallel GC (Garbage Collector) kullanımı için eklenen jvm seçeneği (option)

---

XX=+UseParallelOldGC

Tanım: Java'da Old Generation alanında Parallel GC (Garbage Collector) kullanımı için eklenen jvm seçeneği (option)

---

-XX:+UseParNewGC

Tanım: Java'da farklı bir Paralel GC yöntemi kullanan, Concurrent GC'ler ile birlikte kullanılabilen (UseParNewGC ve UseConcMarkSweepGC birlikte kullanılabilir) jvm seçeneği (option)

---

-XX:+UseConcMarkSweepGC

Tanım: Java'da CMS(Concurrent Mark-Sweep) GC (Garbage Collector) kullanımı için eklenen jvm seçeneği (option)

---

-XX:+UseG1GC

Tanım: JDK 7 update 4'den sonraki versiyonlarda kullanılabilen Garbage First Garbage Collector (G1 GC) kullanımı için eklenen jvm seçeneği (option)

---

HotSpot - Java HotSpot - Java HotSpot Virtual Machine

Tanım: Java 1.3'ten sonra standart olan (daha önce JVM performansı artıran bir engine olarak tanımlanmaktadır) Java Virtual Machine spesifikasyonuna uygun geliştirilen Java Virtual Machine

---

Minor Garbage Collection

Tanım: JVM içinde Young Generation da Eden alanında artık kullanılmamaya başlanan nesneleri Survivor alanına taşıyan Garbage Collection işlemi.

---

Garbage Collection

Tanım: JVM içinde Old Generation dolduğu zaman bu alanda nesneleri temizlemeyen Garbage Collection işlemi.

---

Stop-the-World

Tanım: GC (Garbage Collection) sürecinde tüm thread'lerin durdurulması süreci. GC sürecinde uygulama dışarıdan isteklere cevap vermez ve tüm thread'ler bekler duruma geçer. Minor GC aşaması çok kısa sürdüğü için hissedilmez. Ancak Major GC işlemi nesnelerin sayısı fazla ise hissedilebilir olabilir.

---

-XX: MetaspaceSize

Tanım: Java'da JVM'de Metaspace alanının başlangıç da olması gereken boyutunu vermek için kullanılan parametre.

---

-XX: MaxMetaspaceSize

Tanım: Java'da JVM'de Metaspace alanının maksimum olabilecek boyutunu vermek için kullanılan parametre.

---

-XX: MinMetaspaceFreeRatio

Tanım: Java'da JVM'de Metaspace alanında minimum olabilecek boşluğun boyutunu vermek için kullanılan parametre. Bu değer örneğin 20 girilirse GC (garbage collection) işlemi sonrası %20 kadar bir alan boş bırakılır.

---

-XX: MaxMetaspaceFreeRatio

Tanım: Java'da JVM'de Metaspace alanında maksimum olabilecek boşluğun boyutunu vermek için kullanılan parametre.

---

HotSpot Hafıza Alanı

HotSpot JVM Heap yapısı ve yapıyı kontrol etmek için kullanılan seçenekler gösterilmektedir

---

HotSpot G1 Hafıza Alanı

HotSpot için G1 GC'in hafıza alanı yapısı. Tüm alan benzer alanlara bölünmektedir ve her alan için ayrı Eden ve Survivor alanları olmaktadır

---

Kv:Runtime Data Areas - Çalışma Zamanı Data Alanları

JVM 'nin kullanıdığı ve yönettiği memory (hafıza) alanlarına Runtime Data Areas (Çalışma Zamanı Data Alanları) adı verilir. Şunlardır :

• Heap Area : Çalışma zamanı (runtime) sırasında yaratılan tüm nesnelerin tutulduğu memory alanı. Tüm thread'ler bu alana erişebilir ve thread safe değildir. Heap alanı dolduğu Garbage Collector bellekte temizlik yaparak yer açar. Heap boyutu –Xms1G -Xmx4G şeklinde min ve max verilerek ayarlanabilir.
• Stack Area : Bir Thread'e ait bir method çalıştırılması sırasında method içindeki primitive tip (int, boolean, float vb..) değerleri ile method içinde kullanılan ve Heap Area'da tutulan nesnelere olan referansları saklar. Method çalıştırılması sona erince yaratılan yığın (stack) Stace Area'dan kaldırılır.
• Method Area - Metaspace : Derlenmiş kodlar, sınıf bilgileri, değişkenler, sabitler ve methodlar hakkında meta bilgilerin tutulduğu hafıza alanı. Eski adı Permanent Generation (PermGen) şeklinde idi.
• Program Counter Registers : Bir Thread için hangi komutun çalıştırılacağını tespit etmek için en son hangi method'u çalıştırdığını kaydettiği hafıza alanı. Her thread için ayrı bir PC Resgiter vardır.
• Native Method Stacks : Bir uygulama Java kodu dışında yerel kod blokları (native kod) çalıştırdığında Java Stack Area benzeri tuttuğu hafıza alanı.

---

HotSpot Hafıza Alanı Bölümleri

HotSpot hafıza alanını aşağıdaki gibi bölümlemektedir (Garbage First Garbage Collector öncesi yapı için geçerlidir):

• Young Generation (New Generation) : Yeni yaratılan nesneler
• Eden : İlk defa yaratılan nesneler
• Survivor : İlk defa yaratılan nesnelerin belirli bir zaman sonra aktarıldığı yer
• From
• To
• Virtual
• Old Generation (Tenured Generation) : Eski nesneler
• Tenured
• Virtual
• Permanent (Yeni adı Metaspace) Generation (PermGen) : JVM kendisiyle ilgili nesneler
• Perm
• Virtual

---

G1 GC İçin Seçenekleri Listesi

Aşağıda G1 GC için kullanılabilecek seçeneklerin listesi ve ingilizce açıklamaları görülmektedir :
 

Option and Default Value	Description
-XX:+UseG1GC	Use the Garbage First (G1) Collector
-XX:MaxGCPauseMillis=n	Sets a target for the maximum GC pause time. This is a soft goal, and the JVM will make its best effort to achieve it.
-XX:InitiatingHeapOccupancyPercent=n	Percentage of the (entire) heap occupancy to start a concurrent GC cycle. It is used by GCs that trigger a concurrent GC cycle based on the occupancy of the entire heap, not just one of the generations (e.g., G1). A value of 0 denotes 'do constant GC cycles'. The default value is 45.
-XX:NewRatio=n	Ratio of new/old generation sizes. The default value is 2.
-XX:SurvivorRatio=n	Ratio of eden/survivor space size. The default value is 8.
-XX:MaxTenuringThreshold=n	Maximum value for tenuring threshold. The default value is 15.
-XX:ParallelGCThreads=n	Sets the number of threads used during parallel phases of the garbage collectors. The default value varies with the platform on which the JVM is running.
-XX:ConcGCThreads=n	Number of threads concurrent garbage collectors will use. The default value varies with the platform on which the JVM is running.
-XX:G1ReservePercent=n	Sets the amount of heap that is reserved as a false ceiling to reduce the possibility of promotion failure. The default value is 10.
-XX:G1HeapRegionSize=n	With G1 the Java heap is subdivided into uniformly sized regions. This sets the size of the individual sub-divisions. The default value of this parameter is determined ergonomically based upon heap size. The minimum value is 1Mb and the maximum value is 32Mb.

---

UseSerialGC , UseParallelGC , UseParNewGC (ve UseConcMarkSweepGC), UseG1GC Aynı Anda Kullanılamaz

-XX:+UseSerialGC , -XX:+UseParallelGC , -XX:+UseParNewGC (veya -XX:+UseConcMarkSweepGC), -XX:+UseG1GC farklı Garbage Collector sistemleridir ve aynı anda bu seçeneklerden en fazla bir seçenek kullanılabilir. Bu nedenle bir java uygulaması çalışıtırılrken bunlardan biri seçilmelidir

---

Garbage Collector’ı Çöp Ettiler!

Sahipleri : Yusuf Boyacıgil
Garbage Collector ve core-dump
Oracle aldıktan sonra Java’nın geleceği ile alakalı kaygılarım vardı. Kendi kendime: “Bu paragöz şirket Java’yı aldıktan, James (Gosling) baba’yı da şutladıktan sonra Java’yı bozar” demiştim. Çok geçmeden GC’den ötürü durup dururken “core-dump”lar atmaya başlayınca endişemde haklı olduğum kanısına vardım.
Hikayemiz şöyle gelişti. Bizim bir uygulamamız var. Bunu integrasyon testlerini yapmak için birkaç makineye kurduk. Daha testlere başlamadan “Houston! Bir sorun var!” diye mesajlar almaya başladık. Baktık tabi duruma: Üzerinde yük yok, makine sağlam bir makine, jvm’in en son versiyonu (bi sürü “bug fix” yapılmış olanı), native lib’ler falan hepsi tastamam, ama uygulamanın biri bir-iki saat çalışıp “core” atıyor. Cluster’dan mı lan yoksa diye işkilleniyoruz. JVM aklımıza bile gelmiyor.
Hemen core dump’ları başladık incelemeye. “GCThread”, “GCConcThread” yani ismiyle müsemma Garbage Collector thread’leri yamulmuş. O kadar zamandır Java ile uğraşıyorum. GC ile JVM’in core attığını nadir görmüşümdür. Daha önce de yine başka bir uygulamada GC ile ilgili core’ları yemiştik. jvm versiyonunu yükselttik, GC tuning yaptık, sonra jvm versiyonunu alçalttık falan sorunu bir şekilde çözmüştük.
Tabi, hemen sorun ile ilgili bir google danışmak gerekti. Google da bizi jvm bug veritabanına yönlendirdi. Bizim gibi başkaları da çeşitli jvm versiyonlarında benzer sorunları yaşamışlar. Her bug için farlkı work around’lar var. E haliyle, niyet ettik niyet eyledik work around’ları uygulamaya. Yalnız şöyle bir durum oldu ki bir work around’u uygulayınca bir süre sonra yine core attı. Onu aratıyorsun başka bir çözüm, o çözümü uyguluyorsun yine patlıyor! Böyle günlerce uğraştık.
Her seferinde yeni bir work around, biraz GC tuning, GC’yi gözleme (jvisual vm + gc viewer plugin) yapıp ne oluyor, nasıl oluyor anlamaya çalıştık. Sonunda sorun çözüldü artık core atmıyor. Ama neden atmıyor, ben bilmiyorum henüz. Ya bam telinden yakaladık da uygun GC parametrelerini tutturduk (ki bu olduğuna inanmıyorum) ya da kendiliğinden sorun halloldu veya sizi çok uğraştırdım siz biraz takılın sonra yine başınızı ağrıtırım dedi ve bir gün geri gelecek.
Birkaç örnek vereyim nelerle uğraştık:
Multiple JVM crashes seen with 1.6.0_10 through early access of 1.6.0_14 – possibly related to GC
“core dump”‘lardan biri buraya kadar getirmişti. Çözüm önerisi:
-XX:-ReduceFieldZeroing -XX:-ReduceInitialCardMarks -XX:-ReduceBulkZeroing
parametrelerini kullanın idi. Kullandık yine patladı.

CMS: reference processing crash if ParallelCMSThreads & ParallelGCThreads
Hakkaten bizde de CMS thread sayısı, gc thread’lerden çoktu. Çözüm önerisi:
always use ParallelCMSThreads &= ParallelGCThreads (if modifying them via the command line).
Çözümü uyguladık ama yine patladı.
Netice itibariyle bugünkü yorumum şudur ki: “GC artık çöp olmuştur!”
Hadi diyelim benim durumum bana özel. Her koyun kendi bacağından asılır. Ya da ne biliyim benim derdim elalemi niye gersin. O zaman şuna ne diyeceksiniz: GC Tuning denen bir uzmanlık alanı veya sanat çıktı. Yani memory’yi temizleme işi araç olmaktan çıktı amaç haline geldi! Burada bir enayilik var. Onlarca collector, yüzlerce GC parametresi var. Bu parametreler ile ilgili dokümantasyon eksiği var. Biri ötekini eziyor, diğeri berikiyle yapmak istediğin şeyi etkisiz hale getiriyor, vs. Bu kadar collector ve parametre fazla. Böyle olmaması gerekir. İşin bir diğer ram’ler ucuzladı. Ama jvm heap’inin 4-6 gb üzerinde vermeye başlayınca uzun süren “durdurun dünyayı inecek var!” durumları yaşanıyor ve bu süre bizim işler için kabul edilebilir değil!
Mesela “young gen.”‘i paralel olarak temizlemek için GC’nin harcadığı zaman genellikle kabul edilir oluyor. Buna güvenip diyelim boyutunu artırınca bu sefer young’ın temizlenmesinin uzadığını görüyorsunuz. Uygulamanın yarattığı objeler genellik orta ömürlü ise, young’ın boyunu makul bir seviyede artırıp, survivor space’lerin büyüklüğünü ayarlayıp, tenuring threshold’u max değerine getirip, old’a az ideal de hiç obje atmak için bir tuning yapsanız bile old’a atılmasına ve hatta gc’nin paralel’den seriye düşmesine kesinlikle engel olamıyorsunuz.
CMS “durdurun dünyayı” sendromunun en az olması için şu anda en çok kullanılan toplayıcı. Ama o da compaction yapmadığı yani ölü nesneleri işaretleyip geçtiği, old gen alanında boş alanları bir araya getirmediği için fragmantasyon çok oluyor ve bu mem alloc. performansını etkiliyor. Bunun gibi birçok dikkat edilmesi gereken ve bilinmesi gereken şey var GC ile ilgili.
Netice itibariyle olması gereken şudur:
java -Xmx30g <main-class>
gibi.
Yani uygulamamı max. 30 gb heap ile çalıştır. GC’nin detaylarıyla beni uğraştırma! Madem otomatik mem management yapıyorum diyorsun benden yüz tane hint isteme. Hadi bakiym!
Alıntı Kaynağına Gitmek İçin Tıklayınız

---