Şekil-1 JSM'nin iç yapısı
Farklı işletim sistemlerinde farklı JSM'lerle karşılaşabilirsiniz. Oracle'ın HotSpot'u en çok kullanılan JSM'dir ve hemen hemen her işletim sitemi için HotSpot bulabilirsiniz. Oracle'ın sahip olduğu ama artık geliştirmesini durdurduğu bir JSM daha var: JRockit. Oracle'ın Sun firmasını satın almasından sonra HotSpot ile ilerlemeye karar verdi ve JRockit'in geliştirmesini durdurdu. Onun iyi özelliklerini HotSpot'a aktardığını ve HotSpot'u ticarileştirdiğini görüyoruz. JDK 7u40 sürümü ile birlikte gelen jmc (Mision Control) ve Flight Recorder yeteneğini JRockit'dan almıştır. jmc'nin kişisel kullanımı ücretsizdir, ancak ticari kullanımı için "Oracle ile gelirinizi paylaşmanız" gerekir. Azul Systems'ın biri OpenJDK tabanlı olan Zulu adında destek alabileceğiniz bir JSM'si ve diğeri Zing isimli, büyük Heap alanlarıyla, donma olmadan çalışmayı vaat eden, C4 (Continuously Concurrent Compacting Collector) adında bir çöp toplayıcısı barındıran bir JSM'si daha bulunuyor. IBM'in kendi AIX ve Linux tabanlı sistemleri için geliştirdiği J9 adında bir JSM'si bulunuyor.Java uygulamalarını çalıştırdığınız ortamlarda, farklı mimariler ile karşılaşabilirsiniz. Java SE platformunda uygulama çalıştıracak iseniz tipik yapı Şekil-2'de verilmiştir.
Şekil-2 Java SE Uygulamalarının çalıştığı tipik mimari
Burada en altta tüm işi asıl yapan, fiziksel olarak dokunabileceğimiz donanım yer alır. Onun üzerinde donanım kaynaklarını yönetmekle sorumlu olan işletim sistemi çekirdeği yer alır. JSM ise işletim sistemi üzerinde oturur. Java uygulamalarının platform bağımsız olmasını sağlayan JSM'dir. JSM geliştirdiğimiz uygulamanın byte kodlarını alıp, işlemcinin ve işletim sisteminin anlayacağı makine komutlarına ve sistem çağrılarına dönüştürür. Kurumsal uygulama geliştirmek için ise Java EE platformunu kullanıyoruz. Java EE platformunda uygulama geliştirmek için ise Java EE uyumlu bir uygulama sunucusuna ihtiyaç bulunmaktadır. Uygulama sunucusunun kendisi de bir Java uygulamasıdır ve bu nedenle JSM üzerinde çalışır. Bu durumda Java EE uygulamaları Şekil-3'deki gibi bir mimari üzerinde koşarlar. Java EE uygulama sunucularının bir kısmı açık kaynak kodlu (TomEE, GF, JBoss AS, Wildfly), bir kısmı ücretli (JBoss EAP, Weblogic, WebSphere) ve bir kısmı da kapalı kodludur (Weblogic, WebSphere).
Şekil-3 Java EE Uygulamalarının çalıştığı tipik mimari
Son dönemde güçlü donanımlar ile karşılaşıyoruz. Bu güçlü donanımlar üzerinde, sistem kaynaklarının, uygulamalar arasında daha iyi paylaştırılabilmesi için çeşitli çözümler geliştirildiğini görüyoruz:
- Zone (Solaris)
- Control Groups (Linux)
- Docker (Control Groups ile birlikte kullanılımı)
- Sanallaştırma
Zone ve Control Groups çözümleri Kap (=Container) teknolojisini kullanırlar. Ev sahibi işletim sisteminden, biri birinden yalıtılmış klonlar yaratılır. Bu yaratılan klonlara ihtiyaca göre kaynak atanarak, kaynak kullanımı planlanır. Sanallaştırma çözümünde ise donanım üzerinde ince bir sanallaştırma katmanı oturur. Bu katman üzerinde sanal makinalar tanımlanır. Bu sanal makinalar üzerine ihtiyaca göre farklı işletim sistemleri kurulur. JSM bu işletim sistemleri üzerinde çalışır (Şekil-4).
Şekil-4 Sanallaştırma çözümü ve JSM
JSM'nin İşletim Sistemine ihtiyaç duymayan, doğrudan Sanal Makina üzerinde oturan türleri de mevcuttur (Şekil-5): JRockit VE (Virtual Edition) ve WebSphere HE (Hypervisor Edition).
Şekil-5 Doğrudan sanal makina üzerinde çalışan JSM
HotSpotBu bölümde HotSpot marka Java Sanal Makinasını inceleyeceğiz. HotSpot ona sorulduğunda kendisini tanıtır:
c:\opt32\java\jdk1.7.0_71\bin>java -version
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) Client VM (build 24.71-b01, mixed mode, sharing)
Burada JSM'nin HotSpot marka olduğunu, dağıtım sürümünün 24.71-b01, JDK sürümünün ise 1.7u71 olduğunu anlıyoruz. Ancak burada açıklamam gereken Client VM, mixed mode ve sharing tanımlamaları var. JSM hem 32-bit hem de 64-bit olabilir. Eğer bize açıkça 64-bit olduğunu söylemiyor ise 32-bittir. 64-bitlik bir HotSpot bize kendini aşağıdaki gibi tanıtacaktır:c:\opt64\java\jdk1.7.0_71\bin>java -version
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
Evet, HotSpot kendini 64-bit olarak tanıttı. Bir değişiklik daha dikkatimizi çekiyor: Client VM yazan yerde şimdi Server VM yazıyor! Henüz ne olduklarını bilmiyoruz ama en azından varsayılan olarak, 32-bitlik HotSpot, Client VM özelliğinde ve 64-bitlik HotSpot ise Server VM özelliğinde olduğunu biliyoruz. Önce "mixed mode" özelliğini açıklayalım. HotSpot, uygulamaları başlangıçta yorumlamalı olarak çalıştırır. Basit bir şekilde açıklamak gerekirse, HotSpot çalıştırılacak metodun byte kodlarının x86 karşılıklarını, byte kod-x86 çizelgesinden öğrenir ve x86 komutlarını işlemciye çalıştırması için gönderir. Bu çalışma şekli yavaştır. "mixed mode" çalışma şeklinde uygulama başlangıçta bu yüzden yavaş çalışır. Bir süre sonra HotSpot uygulamanın sıkça çalışan ve ısınan metotlarını JIT (=Just-in-time) derleyicisine gönderir. JIT'lenen metot bundan sonra doğal işlemci komutları olarak çalışacağından, daha hızlı çalışır. Bir süre sonra bakıldığında, çalışan metotların bir kısmı yorumlamalı bir kısmı ise işlemcinin doğal komutlarında çalışır. Java uygulamamız başlangıçta yavaş çalışırken, yavaş yavaş hızlanmaya başlayacaktır. JIT derleyici sadece ana işlemci komutlarına dönüştürme yapmaz, aynı zamanda dinamik en iyileme yöntemlerini uygular. Hızlanmanın asıl kaynağı da buradan gelir. C/C++ ve Java'da yazılmış çözümlerin karşılaştırılmasında, Java'nın bazen daha üstün başarım sergilemesinin nedeni, JIT derleyicisinin uyguladığı bu iyileştirmelerdir. Şekil-6'da JIT derleyicinin basit bir şeması verilmiştir. JIT derleyici içinde basit bir kesit çıkarıcı (=Profiler) vardır ve yazılımın şeklini belirlemeye çalışır. En iyileme teknikleri, yazılımın çalışma zamanında aldığı şekle göre uygulanır. Her en iyileme tekniği her durumda geçerli değildir. JIT derleyici önce JIT'lenecek metodun ya da döngü bloğunun byte kodlarını ara bir gösterime dönüştürür. En iyileyici, yazılımın kesit bilgisinden yararlanarak, yazılımın şekline uygun en iyileme tekniklerini uygular. En iyileme, her durumda ara gösterime uygulanır. Kod üreteci bu ara gösterimden x86 kodu üretir. Kesit çıkarıcı koşturulan kodun davranışından, kesit bilgisini günceller.
Şekil-6 JIT Derleyici
HotSpot içinde iki farklı karakteristikte JIT derleyici bulunur: C1 ve C2. Client VM, C1 derleyicisini ve Server VM ise C2 derleyicisini kullanır. Java uygulamalarının başarımını ölçmek için farklı metrikler kullanarak ölçümler yapabiliriz. Açılış zamanı ve cevap süresi başarımı ölçmek için kullanılabilecek iki ölçüttür. Masaüstü uygulamaları için açılış süresi ve web uygulamaları için ise cevap süresi daha önemlidir. Masaüstü uygulamaları kullanıcı arayüzünü bir an önce kullanıcıya sunmalıdır. Örneğin, e-posta göndermek istiyorsunuz, bunun için favori e-posta istemcinizin (örneğin, Thunderbird) masaüstü simgesine tıkladınız. Pencerenin beş dakika sonra açılması sizi hiç memnun etmez. Pencerenin hemen açılmasını ve iletinizi bir an önce yazabilmeyi istersiniz. Nasıl olsa yazmaya başladığınızda, işlemci ile karşılaştırıldığında kaplumbağa hızında yazıyor olacaksınız. Yazılımın çok da hızlı çalışmaya ihtiyacı yok. Buna karşılık web uygulamalarında ise uygulama sunucusunun biraz geç açılmasına tahammül edebilirsiniz ama bir istek geldiğinde ona en hızlı sürede yanıt vermek ve cevabı dönebilmek istersiniz. İşte C1 derleyicisi açılış süresini iyileştirmek ve C2 derleyicisi ise hızlı yanıt süresini iyileştirmek üzere en iyilenmiştir. 32-bitlik HotSpot hem Client VM hem de Server VM olarak çalışabilirken, 64-bitlik HotSpot sadece Server VM olarak çalışır. -client ve -server seçenekleri ile tercihimizi HotSpot'a bildirebiliyoruz:c:\opt64\java\jdk1.7.0_71\bin>java -client -version
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
c:\opt64\java\jdk1.7.0_71\bin>java -server -version
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
c:\opt32\java\jdk1.7.0_71\bin>java -client -version
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) Client VM (build 24.71-b01, mixed mode, sharing)
c:\opt32\java\jdk1.7.0_71\bin>java -server -version
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) Server VM (build 24.71-b01, mixed mode)
C1 en iyileme için acele eder. Amacı açılış süresini iyileştirmek olduğu için çok fazla en iyileme yapmaz. C2 ise JIT'lemek için acele etmez, önce uygulamanın şeklini alması bekler ve daha çok en iyileme tekniklerini uygular. Bu nedenle C1'in JIT'leme zaman maliyeti düşüktür ama buna paralel olarak, üretilen kodun kalitesi de düşüktür. C2'nin JIT'leme zaman maliyeti yüksektir ancak üretilen kodun kalitesi yüksektir. C2'nin ürettiği kod C1'in ürettiği koddan yaklaşık iki kat daha hızlı çalışır.
Java 7'de her iki JIT derleyicinin iyi özelliklerini birleştiren yeni bir JIT derleyicisi var: Katmanlı JIT derleyici (=Tiered Compiler). Hem açılış zamanını hem de cevap süresini iyileştirmeye çalışıyor. Şekil-7'de katmanlı JIT derleyicinin basit akış şemasını bulabilirsiniz.
Şekil-7 Katmanlı JIT Derleyici
Ancak Java 7'de bu özellik kapalıdır. Açmak için JSM'yi -XX:+TieredCompilation seçeneği ile başlatmanız gerekir. Java 8'de ise varsayılan davranış budur, bu nedenle herhangi bir tanımlama yapmanıza gerek yoktur. JIT derleyicinin davranışını izleyebilirsiniz. Hatta üretilen x86 kodunu da izlemek mümkündür. Bunun için HotSpot'u aşağıdaki gibi başlatmalısınız:
-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompilation -XX:+PrintAssembly
Ayrıca Windows platformu için hsdis-amd64.dll dosyasını java.exe ile aynı dizine koymanız gerekir. Bu dll dosya, x86 komutlarının sembolik dilde göstermesini sağlar. Ekran çıktısına ilişkin bir örneği aşağıda bulabilirsiniz:
Java HotSpot(TM) 64-Bit Server VM warning: PrintAssembly is enabled; turning on DebugNonSafepoints to gain additional output 142 1 java.lang.String::hashCode (55 bytes) Loaded disassembler from hsdis-amd64.dll Decoding compiled method 0x00000000024ebd10: Code: [Disassembling for mach='i386:x86-64'] [Entry Point] [Constants] # {method} 'hashCode' '()I' in 'java/lang/String' # [sp+0x30] (sp of caller) 0x00000000024ebe40: mov 0x8(%rdx),%r10d 0x00000000024ebe44: cmp %r10,%rax 0x00000000024ebe47: jne 0x00000000024b7a60 ; {runtime_call} 0x00000000024ebe4d: data32 xchg %ax,%ax [Verified Entry Point] 0x00000000024ebe50: mov %eax,-0x6000(%rsp) 0x00000000024ebe57: push %rbp 0x00000000024ebe58: sub $0x20,%rsp ;*synchronization entry ; - java.lang.String::hashCode@-1 (line 1446) 0x00000000024ebe5c: mov %rdx,%r13 0x00000000024ebe5f: mov 0x10(%rdx),%eax ;*getfield hash ; - java.lang.String::hashCode@1 (line 1446) 0x00000000024ebe62: test %eax,%eax 0x00000000024ebe64: jne 0x00000000024ebf44 ;*ifne ; - java.lang.String::hashCode@6 (line 1447) 0x00000000024ebe6a: mov 0xc(%rdx),%esi ;*getfield value ; - java.lang.String::hashCode@10 (line 1447) 0x00000000024ebe6d: mov 0xc(%rsi),%r10d ;*arraylength ; - java.lang.String::hashCode@13 (line 1447) ; implicit exception: dispatches to 0x00000000024ebf65 0x00000000024ebe71: xor %edi,%edi 0x00000000024ebe73: test %r10d,%r10d 0x00000000024ebe76: jle 0x00000000024ebf50 ;*ifle ; - java.lang.String::hashCode@14 (line 1447) 0x00000000024ebe7c: test %r10d,%r10d 0x00000000024ebe7f: jbe 0x00000000024ebf54 0x00000000024ebe85: mov %r10d,%r8d 0x00000000024ebe88: dec %r8d 0x00000000024ebe8b: cmp %r10d,%r8d 0x00000000024ebe8e: jae 0x00000000024ebf54 0x00000000024ebe94: xor %ebp,%ebp ;*imul ; - java.lang.String::hashCode@36 (line 1451) 0x00000000024ebe96: movzwl 0x10(%rsi,%rdi,2),%r9d 0x00000000024ebe9c: add %r9d,%ebp ;*iadd ; - java.lang.String::hashCode@40 (line 1451) 0x00000000024ebe9f: mov %ebp,%ecx 0x00000000024ebea1: shl $0x5,%ecx 0x00000000024ebea4: mov %ecx,%eax 0x00000000024ebea6: sub %ebp,%eax ;*imul ; - java.lang.String::hashCode@36 (line 1451) 0x00000000024ebea8: inc %edi ;*iinc ; - java.lang.String::hashCode@42 (line 1450) 0x00000000024ebeaa: cmp $0x1,%edi 0x00000000024ebead: jge 0x00000000024ebeb3 ;*if_icmpge ; - java.lang.String::hashCode@30 (line 1450)
154 1 java.lang.String::hashCode (55 bytes) 203 2 java.lang.String::indexOf (70 bytes) 226 3 sun.java2d.loops.GraphicsPrimitive::getUniqueID (5 bytes) 249 4 java.lang.Object::<init> (1 bytes) 257 5 java.lang.String::charAt (29 bytes) 341 6 java.lang.String::equals (81 bytes) 343 7 java.util.Arrays::binarySearch0 (95 bytes) 383 8 % sun.awt.image.PNGImageDecoder::update_crc @ 3 (41 bytes) 383 9 % ! sun.awt.image.PNGImageDecoder::produceImage @ 960 (1920 bytes) 391 10 sun.awt.image.PNGImageDecoder::update_crc (41 bytes) 419 9 % ! sun.awt.image.PNGImageDecoder::produceImage @ -2 (1920 bytes) made not entrant 420 11 % ! sun.awt.image.PNGImageDecoder::produceImage @ 960 (1920 bytes) 420 12 n java.lang.System::arraycopy (native) (static) 421 13 sun.awt.image.PNGImageDecoder::filterRow (459 bytes) 461 14 java.util.Properties$LineReader::readLine (452 bytes) 568 15 sun.security.provider.SHA::implCompress (491 bytes) 575 16 java.lang.String::lastIndexOf (52 bytes) 581 17 sun.nio.cs.SingleByte$Encoder::encode (114 bytes) 586 18 sun.nio.cs.SingleByte$Encoder::encode (32 bytes) 596 19 java.lang.Math::min (11 bytes) 604 20 java.nio.HeapByteBuffer::_get (7 bytes) 610 21 java.io.BufferedInputStream::getBufIfOpen (21 bytes) 610 22 s java.io.BufferedInputStream::read (49 bytes) 611 23 java.io.FilterInputStream::read (8 bytes) 613 24 java.io.DataInputStream::readChar (40 bytes) 614 25 % sun.text.normalizer.CharTrie::unserialize @ 29 (74 bytes) 622 26 sun.text.normalizer.CharTrie::unserialize (74 bytes) 637 27 java.nio.Buffer::nextGetIndex (31 bytes) 651 28 java.lang.String::length (6 bytes) 656 29 java.awt.geom.Path2D$Float::append (216 bytes) 656 30 java.awt.geom.Path2D$Iterator::isDone (20 bytes) 657 31 java.awt.geom.Path2D$Float::needRoom (123 bytes) 661 32 java.awt.geom.Path2D$Float$CopyIterator::currentSegment (39 bytes) 663 33 java.awt.geom.Path2D$Iterator::next (35 bytes) 718 34 java.util.HashMap::indexFor (6 bytes) 724 35 java.nio.Bits::getCharB (16 bytes) 724 36 java.nio.Bits::makeChar (12 bytes) 725 37 java.nio.ByteBufferAsCharBufferB::get (16 bytes) 725 38 java.nio.ByteBufferAsCharBufferB::ix (9 bytes) 738 39 java.lang.String::indexOf (166 bytes) 738 40 java.lang.String::replace (127 bytes) 755 41 java.util.HashMap::hash (55 bytes) 769 42 java.lang.String::startsWith (72 bytes) 772 43 java.util.HashMap::getEntry (86 bytes) 783 44 java.util.concurrent.atomic.AtomicInteger::get (5 bytes)
- %: Döngü bloğu JIT'lendi. Metod içinde birden fazla döngü varsa hangi döngü olduğunu @ sembolünden sonra yazan rakamı kullanarak belirleyebilirsiniz. Bu rakam döngünün başlangıç byte kod sırasını verir.
- s: synchronized metod JIT'lendi
- !: Exception bloğu JIT'lendi
- n: native metod
Dördüncü sütunda ise JIT'lenen metodun paket ile birlikte adı yer alır. Ne yazık ki işlev yüklenen metodları ayırt etmek her zaman kolay olmayabilir. Parantez içinde metodun gövdesinin kaç byte koddan oluştuğu bilgisi bulunur. İşlev yüklenen metodları ayırt etmek için bu değerden yararlanabilirsiniz.
HotSpot'un varsayılan çalışma kipi "mixed"'dir. İki farklı kipi daha bulunur:
- Compiled: Tüm metodlar JIT'lenerek çalıştırılır. Bu kipte çalışmak için HotSpot'u -Xcomp seçeneği ile çalıştırmalısınız:
c:\opt64\java\jdk1.7.0_71\bin>java -Xcomp -version
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, compiled mode)
Uygulama sunucularını üretim ortamında bu kipte çalışan HotSpot üzerinde çalıştırmanız uygun olur.
- Interpreted: JIT derleyiciler devre dışıdır. Tüm kod yorumlamalı olarak çalıştırılır. Zamanda yolculuk yapmak için bu kipi kullanabilirsiniz: Java ilk çıktığında çok yavaştı, çünkü sadece bu kipte çalışıyordu. Bu yavaşlığı deneyimlemek ve 1996'ya gitmek için -Xinterp seçeneği ile çalıştırmanız yeterli olacaktır:
c:\opt64\java\jdk1.7.0_71\bin>java -Xinterp -version
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, interpreted mode)
Java uygulamalarını çalıştırmak çok kolaydır. jar olarak dağıtılan bir uygulamayı komut satırından çalıştırmak için "java -jar" yazmak yeterlidir. Ancak JSM'nin komut satırından verebileceğimiz çok sayıda seçeneği bulunur. HotSpot için bu seçeneklerin listesini almak üzere, java'yı aşağıdaki seçeneklerle birlikte yazıp, çalıştırın:
java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version
Bu komut ekranda yüzlerce satırdan oluşan bir çıktı yaratır:
[Global flags]
uintx AdaptivePermSizeWeight = 20 {product}
uintx AdaptiveSizeDecrementScaleFactor = 4 {product}
uintx AdaptiveSizeMajorGCDecayTimeScale = 10 {product}
uintx AdaptiveSizePausePolicy = 0 {product}
uintx AdaptiveSizePolicyCollectionCostMargin = 50 {product}
uintx AdaptiveSizePolicyInitializingSteps = 20 {product}
uintx AdaptiveSizePolicyOutputInterval = 0 {product}
uintx AdaptiveSizePolicyWeight = 10 {product}
uintx AdaptiveSizeThroughPutPolicy = 0 {product}
uintx AdaptiveTimeWeight = 25 {product}
bool AdjustConcurrency = false {product}
bool AggressiveOpts = false {product}
intx AliasLevel = 3 {C2 produc
bool AlignVector = false {C2 produc
intx AllocateInstancePrefetchLines = 1 {product}
intx AllocatePrefetchDistance = 192 {product}
intx AllocatePrefetchInstr = 0 {product}
intx AllocatePrefetchLines = 4 {product}
intx AllocatePrefetchStepSize = 64 {product}
intx AllocatePrefetchStyle = 1 {product}
bool AllowJNIEnvProxy = false {product}
bool AllowNonVirtualCalls = false {product}
bool AllowParallelDefineClass = false {product}
bool AllowUserSignalHandlers = false {product}
bool AlwaysActAsServerClassMachine = false {product}
bool AlwaysCompileLoopMethods = false {product}
bool AlwaysLockClassLoader = false {product}
bool AlwaysPreTouch = false {product}
bool AlwaysRestoreFPU = false {product}
. . . . . . . . . . . .
64-bitlik Server VM HotSpot için tam olarak 758 seçenek vardır. 32-bitlik Client VM HotSpot için 685 seçenek ve 32-bitlik Server VM HotSpot için ise 756 seçenek bulunuyor. Bu JDK 7u71 için böyle. JDK 8u40 için ise seçenek sayılarında farklılıklar var:
64-bitlik Server VM HotSpot 790 seçenek, 32-bitlik Client VM HotSpot için 709 seçenek ve 32-bitlik Server VM HotSpot için ise 787 seçenek bulunuyor. Bu çıktıda birinci satırda seçeneğin tipi var. bool true/false değer alabilen seçeneği ifade eder. intx tamsayı, uintx pozitif tamsayıyı ve double ise kayan nokta sayıları ifade eder. İkinci sütunda değişkenin adı ve üçüncü sütunda ise varsayılan değeri bulunur. Eğer değişkenin değeri := sembolü ile verilmiş ise bu seçeneğin değeri kullanıcı tarafından ezilmiş demektir:
intx CICompilerCount := 3 {product}
Seçeneklerin değerini değiştirmek için komut satırında seçeneğin önüne "-XX:" koyup yeni değerini "=" sembolünden sonra tanımlıyoruz:
-XX:CompileThreshold=2000
Tek bir özel durum var. bool tipindeki seçenekler için true ve false yerine + ve - sembollerini seçenek adından hemen önce kullanıyoruz:
-XX:+AggressiveOpts
ya da
-XX:+AggressiveOpts
Dördüncü sütunda ise seçeneğin sınıfı yer alır.
HotSpot seçeneklerini oluşturan kümeye JSM ergonomisi diyoruz. JSM, ergonomisini üzerinde çalıştığı platform kaynaklarının (bellek ve işlemci gibi) kapasitesine göre belirler. Bazı seçeneklerinin değerlerini kaynakların durumuna göre otomatik olarak uyarlayarak saptar. Diğer seçeneklerin ise varsayılan sabit başlangıç değerleri vardır. JSM'nin otomatik olarak belirlediği bu seçenekler, JSM'yi akort etmek için kullanılabilir. JSM'nin nasıl akort edileceği ve HotSpot ile ilgili detay bilgi edinmek isteyenler için Java Performance Tuning and Optimization eğitimini tavsiye ederim.
Aslında HotSpot'un bu listenenenden daha da fazla seçeneği bulunur. Tüm seçeneklerin listesini almak için HotSpot'u aşağıdaki seçeneklerle çalıştırmalısınız:
java -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -XX:+AggressiveOpts -XX:+PrintFlagsFinal -version
JDK 8u40 için tüm seçenek sayıları:
64-bitlik Server VM HotSpot 834 seçenek, 32-bitlik Client VM HotSpot için 751 seçenek ve 32-bitlik Server VM HotSpot için ise 831 seçenek bulunuyor.
HotSpot seçeneklerini oluşturan kümeye JSM ergonomisi diyoruz. JSM, ergonomisini üzerinde çalıştığı platform kaynaklarının (bellek ve işlemci gibi) kapasitesine göre belirler. Bazı seçeneklerinin değerlerini kaynakların durumuna göre otomatik olarak uyarlayarak saptar. Diğer seçeneklerin ise varsayılan sabit başlangıç değerleri vardır. JSM'nin otomatik olarak belirlediği bu seçenekler, JSM'yi akort etmek için kullanılabilir. JSM'nin nasıl akort edileceği ve HotSpot ile ilgili detay bilgi edinmek isteyenler için Java Performance Tuning and Optimization eğitimini tavsiye ederim.
Aslında HotSpot'un bu listenenenden daha da fazla seçeneği bulunur. Tüm seçeneklerin listesini almak için HotSpot'u aşağıdaki seçeneklerle çalıştırmalısınız:
java -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -XX:+AggressiveOpts -XX:+PrintFlagsFinal -version
JDK 8u40 için tüm seçenek sayıları:
64-bitlik Server VM HotSpot 834 seçenek, 32-bitlik Client VM HotSpot için 751 seçenek ve 32-bitlik Server VM HotSpot için ise 831 seçenek bulunuyor.
No comments:
Post a Comment