java(1) ابزارهای پایه java(1)

java - اجرای یک برنامهٔ جاوا

java [options] classname [args]
java [options] -jar filename [args]

options

گزینه‌های خط فرمان که با فاصله از یکدیگر جدا می‌شوند. بخش گزینه‌ها را ببینید.

classname

نام کلاسی که باید اجرا شود.

filename

نام فایل بایگانی جاوا (JAR) که باید فراخوانی شود. تنها همراه با گزینهٔ -jar به کار می‌رود.

args

آرگومان‌هایی که با فاصله از یکدیگر جدا شده و به متد main() ارسال می‌شوند.

دستور java یک برنامهٔ جاوا را آغاز می‌کند. این کار با راه‌اندازی محیط زمان اجرای جاوا (JRE)، بارگذاری کلاس مشخص‌شده و فراخوانی متد main() آن کلاس انجام می‌شود. این متد باید به‌صورت public و static تعریف شده باشد، نباید هیچ مقداری را برگرداند، و باید یک آرایه از نوع String را به عنوان پارامتر بپذیرد. تعریف متد به شکل زیر است:

public static void main(String[] args)

دستور java می‌تواند برای راه‌اندازی یک برنامهٔ JavaFX با بارگذاری کلاسی که دارای متد main() بوده یا کلاس javafx.application.Application را گسترش داده است، استفاده شود. در حالت دوم، راه‌انداز یک نمونه از کلاس Application می‌سازد، متد init() آن را فراخوانی می‌کند، و سپس متد start(javafx.stage.Stage) را فرا می‌خواند.

به‌طور پیش‌فرض، نخستین آرگومانی که گزینهٔ دستور java نباشد، نام کاملاً واجد شرایط (fully qualified name) کلاسی است که باید فراخوانی شود. در صورت مشخص شدن گزینهٔ -jar، آرگومان آن نام فایل JAR حاوی کلاس‌ها و فایل‌های منبع (resource) برای برنامه خواهد بود. کلاس آغازین باید توسط سرآیند مانیفست Main-Class در کد منبع آن مشخص شده باشد.

محیط JRE کلاس آغازین (و سایر کلاس‌های مورد استفادهٔ برنامه) را در سه مجموعه مکان جستجو می‌کند: مسیر کلاس راه‌انداز (bootstrap class path)، افزونه‌های نصب‌شده، و مسیر کلاس (class path) کاربر.

آرگومان‌های پس از نام فایل کلاس یا نام فایل JAR به متد main() ارسال می‌شوند.

دستور java از طیف گسترده‌ای از گزینه‌ها پشتیبانی می‌کند که می‌توان آن‌ها را به دسته‌های زیر تقسیم کرد:

•گزینه‌های استاندارد
•گزینه‌های غیراستاندارد
•گزینه‌های پیشرفتهٔ زمان اجرا
•گزینه‌های پیشرفتهٔ کامپایلر JIT
•گزینه‌های پیشرفتهٔ سرویس‌پذیری (Serviceability)
•گزینه‌های پیشرفتهٔ بازیافت حافظه (Garbage Collection)

پشتیبانی از گزینه‌های استاندارد توسط تمام پیاده‌سازی‌های ماشین مجازی جاوا (JVM) تضمین شده است. آن‌ها برای اقدامات رایج مانند بررسی نسخهٔ JRE، تنظیم مسیر کلاس، فعال‌سازی خروجی پرگو (verbose)، و غیره استفاده می‌شوند.

گزینه‌های غیراستاندارد گزینه‌هایی عمومی هستند که به Java HotSpot Virtual Machine اختصاص دارند؛ بنابراین پشتیبانی از آن‌ها توسط تمام پیاده‌سازی‌های JVM تضمین نمی‌شود و ممکن است دستخوش تغییر شوند. این گزینه‌ها با -X آغاز می‌شوند.

استفادهٔ روزمره و عادی از گزینه‌های پیشرفته توصیه نمی‌شود. این‌ها گزینه‌های توسعه‌دهنده هستند که برای تنظیم بخش‌های خاصی از عملکرد Java HotSpot Virtual Machine به کار می‌روند که معمولاً نیازمندی‌های سیستمی ویژه‌ای دارند و ممکن است به دسترسی مجاز (ممتاز) به پارامترهای پیکربندی سیستم نیاز داشته باشند. پشتیبانی از آن‌ها نیز توسط تمام پیاده‌سازی‌های JVM تضمین نمی‌شود و ممکن است تغییر کنند. گزینه‌های پیشرفته با -XX آغاز می‌شوند.

برای اطلاع از گزینه‌هایی که در آخرین نسخه منسوخ یا حذف شده‌اند، بخشی به نام Deprecated and Removed Options در انتهای این سند قرار دارد.

گزینه‌های بولی (Boolean) برای فعال‌سازی قابلیتی که به‌طور پیش‌فرض غیرفعال است یا غیرفعال‌سازی قابلیتی که به‌طور پیش‌فرض فعال است به کار می‌روند. چنین گزینه‌هایی به پارامتر نیاز ندارند. گزینه‌های بولی -XX با استفاده از علامت مثبت (-XX:+OptionName) فعال و با علامت منفی (-XX:-OptionName) غیرفعال می‌شوند.

برای گزینه‌هایی که به یک آرگومان نیاز دارند، آرگومان ممکن است با یک فاصله، دو‌نقطه (:) یا علامت مساوی (=) از نام گزینه جدا شود، یا ممکن است مستقیماً پس از گزینه قرار گیرد (ساختار دقیق برای هر گزینه متفاوت است). در صورتی که لازم باشد اندازه را به بایت مشخص کنید، می‌توانید پسوندی نگذارید یا از پسوند k یا K برای کیلوبایت (KB)، m یا M برای مگابایت (MB)، و g یا G برای گیگابایت (GB) استفاده کنید. برای نمونه، جهت تنظیم اندازه روی 8 گیگابایت، می‌توانید هر یک از مقادیر 8g، 8192m، 8388608k یا 8589934592 را به عنوان آرگومان مشخص نمایید. اگر لازم باشد درصد مشخص شود، از عددی بین 0 تا 1 استفاده کنید (برای نمونه، 0.25 را برای 25% مشخص کنید)..SS "گزینه‌های استاندارد (Standard Options)"

این‌ها پرکاربردترین گزینه‌هایی هستند که توسط تمام پیاده‌سازی‌های JVM پشتیبانی می‌شوند.

-agentlib:libname[=options]

کتابخانه عامل بومی (native agent library) مشخص‌شده را بارگذاری می‌کند. پس از نام کتابخانه، می‌توان از فهرستی از گزینه‌های تفکیک‌شده با کاما که مختص آن کتابخانه هستند استفاده کرد.

اگر گزینه -agentlib:foo مشخص شود، JVM تلاش می‌کند تا کتابخانه‌ای به نام libfoo.so را در مکانی که توسط متغیر سیستمی LD_LIBRARY_PATH مشخص شده است (در OS X این متغیر DYLD_LIBRARY_PATH است) بارگذاری کند.

مثال زیر نحوه بارگذاری کتابخانه ابزار پروفایلینگ هیپ (HPROF) و دریافت اطلاعات نمونه‌برداری CPU در هر ۲۰ میلی‌ثانیه، با عمق پشته ۳ را نشان می‌دهد:

-agentlib:hprof=cpu=samples,interval=20,depth=3
مثال زیر نحوه بارگذاری کتابخانه Java Debug Wire Protocol (JDWP) و شنود اتصال سوکت روی درگاه ۸۰۰۰، و تعلیق JVM پیش از بارگذاری کلاس اصلی را نشان می‌دهد: 
-agentlib:jdwp=transport=dt_socket,server=y,address=8000
برای کسب اطلاعات بیشتر درباره کتابخانه‌های عامل بومی، به موارد زیر مراجعه کنید:
•توضیحات بسته java.lang.instrument در http://docs.oracle.com/javase/8/docs/api/java/lang/instrument/package-summary.html
•بخش Agent Command Line Options در راهنمای JVM Tools Interface در http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#starting

-agentpath:pathname[=options]

کتابخانه عامل بومی مشخص‌شده با نام مسیر مطلق را بارگذاری می‌کند. این گزینه معادل -agentlib است اما از مسیر کامل و نام فایل کتابخانه استفاده می‌کند.

-client

ماشین مجازی Java HotSpot Client VM را انتخاب می‌کند. نسخه ۶۴بیتی Java SE Development Kit (JDK) در حال حاضر این گزینه را نادیده گرفته و در عوض از Server JVM استفاده می‌کند.

برای انتخاب پیش‌فرض JVM، به Server-Class Machine Detection در http://docs.oracle.com/javase/8/docs/technotes/guides/vm/server-class.html مراجعه کنید.

-Dproperty=value

مقدار یک ویژگی سیستمی را تنظیم می‌کند. متغیر property یک رشته بدون فاصله است که نام ویژگی را نشان می‌دهد. متغیر value رشته‌ای است که مقدار ویژگی را مشخص می‌کند. اگر value رشته‌ای شامل فاصله باشد، آن را درون علامت‌های نقل‌قول قرار دهید (برای مثال -Dfoo="foo bar";).

-d32

برنامه را در یک محیط ۳۲بیتی اجرا می‌کند. اگر یک محیط ۳۲بیتی نصب نشده باشد یا پشتیبانی نشود، خطایی گزارش خواهد شد. به‌طور پیش‌فرض، برنامه در یک محیط ۳۲بیتی اجرا می‌شود مگر اینکه از یک سیستم ۶۴بیتی استفاده شود.

-d64

برنامه را در یک محیط ۶۴بیتی اجرا می‌کند. اگر یک محیط ۶۴بیتی نصب نشده باشد یا پشتیبانی نشود، خطایی گزارش خواهد شد. به‌طور پیش‌فرض، برنامه در یک محیط ۳۲بیتی اجرا می‌شود مگر اینکه از یک سیستم ۶۴بیتی استفاده شود.

در حال حاضر تنها Java HotSpot Server VM از عملیات ۶۴بیتی پشتیبانی می‌کند، و گزینه -server با استفاده از -d64 به‌طور ضمنی اعمال می‌شود. گزینه -client با استفاده از -d64 نادیده گرفته می‌شود. این موضوع ممکن است در نسخه‌های بعدی تغییر کند.

-disableassertions[:[packagename]...|:classname]
-da[:[packagename]...|:classname]

ارزیابی ادعاها (assertions) را غیرفعال می‌کند. به‌طور پیش‌فرض، ارزیابی ادعاها در تمام بسته‌ها و کلاس‌ها غیرفعال است.

بدون آرگومان، -disableassertions (-da) ادعاها را در تمام بسته‌ها و کلاس‌ها غیرفعال می‌کند. با آرگومان packagename که به ... ختم می‌شود، این سوییچ ادعاها را در بسته مشخص‌شده و تمام زیربسته‌های آن غیرفعال می‌کند. اگر آرگومان صرفاً ... باشد، این سوییچ ادعاها را در بسته بدون نام در دایرکتوری کاری فعلی غیرفعال می‌کند. با آرگومان classname، این سوییچ ادعاها را در کلاس مشخص‌شده غیرفعال می‌کند.

گزینه -disableassertions (-da) بر روی تمام بارگذارنده‌های کلاس (class loaders) و کلاس‌های سیستمی (که فاقد بارگذارنده کلاس هستند) اعمال می‌شود. یک استثنا برای این قاعده وجود دارد: اگر این گزینه بدون هیچ آرگومانی ارائه شود، بر روی کلاس‌های سیستمی اعمال نخواهد شد. این امر غیرفعال کردن ادعاها را در تمام کلاس‌ها به‌جز کلاس‌های سیستمی آسان می‌کند. گزینه -disablesystemassertions به شما امکان می‌دهد ادعاها را در تمام کلاس‌های سیستمی غیرفعال کنید.

برای فعال‌سازی صریح ادعاها در بسته‌ها یا کلاس‌های مشخص، از گزینه -enableassertions (-ea) استفاده کنید. هر دو گزینه را می‌توان به‌طور همزمان استفاده کرد. برای مثال، جهت اجرای برنامه MyClass با ادعاهای فعال در بسته com.wombat.fruitbat (و تمام زیربسته‌های آن) اما غیرفعال در کلاس com.wombat.fruitbat.Brickbat، از دستور زیر استفاده کنید:

java -ea:com.wombat.fruitbat... -da:com.wombat.fruitbat.Brickbat MyClass

-disablesystemassertions
-dsa

ادعاها را در تمام کلاس‌های سیستمی غیرفعال می‌کند.

-enableassertions[:[packagename]...|:classname]
-ea[:[packagename]...|:classname]

ادعاها (assertions) را فعال می‌کند. به‌طور پیش‌فرض، ادعاها در تمام بسته‌ها و کلاس‌ها غیرفعال هستند.

بدون آرگومان، -enableassertions (-ea) ادعاها را در تمام بسته‌ها و کلاس‌ها فعال می‌کند. با آرگومان packagename که به ... ختم می‌شود، این سوییچ ادعاها را در بسته مشخص‌شده و تمام زیربسته‌های آن فعال می‌کند. اگر آرگومان صرفاً ... باشد، این سوییچ ادعاها را در بسته بدون نام در دایرکتوری کاری فعلی فعال می‌کند. با آرگومان classname، این سوییچ ادعاها را در کلاس مشخص‌شده فعال می‌کند.

گزینه -enableassertions (-ea) بر روی تمام بارگذارنده‌های کلاس و کلاس‌های سیستمی (که فاقد بارگذارنده کلاس هستند) اعمال می‌شود. یک استثنا برای این قاعده وجود دارد: اگر این گزینه بدون هیچ آرگومانی ارائه شود، بر روی کلاس‌های سیستمی اعمال نخواهد شد. این امر فعال‌سازی ادعاها را در تمام کلاس‌ها به‌جز کلاس‌های سیستمی آسان می‌کند. گزینه -enablesystemassertions یک سوییچ جداگانه برای فعال‌سازی ادعاها در تمام کلاس‌های سیستمی فراهم می‌کند..sp برای غیرفعال‌سازی صریح ادعاها (assertions) در بسته‌ها یا کلاس‌های مشخص، از گزینهٔ -disableassertions (-da) استفاده کنید. اگر یک دستور منفرد شامل چندین نمونه از این سوییچ‌ها باشد، پیش از بارگذاری هر کلاسی به ترتیب پردازش می‌شوند. به عنوان مثال، برای اجرای برنامهٔ MyClass در حالی که ادعاها تنها در بستهٔ com.wombat.fruitbat (و تمامی زیربسته‌های آن) فعال بوده اما در کلاس com.wombat.fruitbat.Brickbat غیرفعال باشند، از دستور زیر استفاده کنید:

java -ea:com.wombat.fruitbat... -da:com.wombat.fruitbat.Brickbat MyClass

-enablesystemassertions
-esa

ادعاها (assertions) را در تمام کلاس‌های سیستم فعال می‌کند.

-help
-?

اطلاعات نحوهٔ استفاده از دستور java را بدون اجرای واقعی JVM نمایش می‌دهد.

-jar filename

برنامه‌ای کپسوله‌شده در یک فایل JAR را اجرا می‌کند. آرگومان filename نام یک فایل JAR به همراه مانیفستی است که خطی به شکل Main-Class:classname دارد؛ خطی که کلاسی را با متد public static void main(String[] args) تعریف می‌کند که به عنوان نقطهٔ شروع برنامه شما عمل می‌کند.

هنگامی که از گزینهٔ -jar استفاده می‌کنید، فایل JAR مشخص‌شده منبع تمامی کلاس‌های کاربر خواهد بود و سایر تنظیمات class path نادیده گرفته می‌شوند.

برای اطلاعات بیشتر در مورد فایل‌های JAR، منابع زیر را ببینید:

•jar(1)
•راهنمای The Java Archive (JAR) Files در http://docs.oracle.com/javase/8/docs/technotes/guides/jar/index.html
•درس: Packaging Programs in JAR Files در

http://docs.oracle.com/javase/tutorial/deployment/jar/index.html

-javaagent:jarpath[=options]

عامل (agent) مشخص‌شدهٔ زبان برنامه‌نویسی Java را بارگذاری می‌کند. برای اطلاعات بیشتر پیرامون ابزارسازی (instrumenting) برنامه‌های Java، به توضیحات بستهٔ java.lang.instrument در مستندات Java API در http://docs.oracle.com/javase/8/docs/api/java/lang/instrument/package-summary.html مراجعه کنید.

-jre-restrict-search

محیط‌های JRE اختصاصی کاربر را در جستجوی نسخه لحاظ می‌کند.

-no-jre-restrict-search

محیط‌های JRE اختصاصی کاربر را از جستجوی نسخه مستثنی می‌کند.

-server

ماشین مجازی Java HotSpot Server VM را انتخاب می‌کند. نسخهٔ ۶۴ بیتی JDK فقط از Server VM پشتیبانی می‌کند، بنابراین در آن حالت این گزینه ضمنی است.

برای انتخاب پیش‌فرض JVM، بخش Server-Class Machine Detection را در http://docs.oracle.com/javase/8/docs/technotes/guides/vm/server-class.html ببینید.

-showversion

اطلاعات نسخه را نمایش داده و اجرای برنامه را ادامه می‌دهد. این گزینه معادل گزینهٔ -version است، با این تفاوت که گزینهٔ دوم به JVM دستور می‌دهد پس از نمایش اطلاعات نسخه خارج شود.

-splash:imgname

صفحهٔ اسپلش (splash screen) را با تصویر مشخص‌شده توسط imgname نمایش می‌دهد. به عنوان مثال، برای نمایش فایل splash.gif از دایرکتوری images هنگام شروع برنامه، از گزینهٔ زیر استفاده کنید: 
-splash:images/splash.gif

-verbose:class

اطلاعات مربوط به هر کلاس بارگذاری‌شده را نمایش می‌دهد.

-verbose:gc

اطلاعات مربوط به هر رویداد جمع‌آوری زباله (GC) را نمایش می‌دهد.

-verbose:jni

اطلاعات مربوط به استفاده از متدهای بومی (native) و سایر فعالیت‌های رابط بومی جاوا (JNI) را نمایش می‌دهد.

-version

اطلاعات نسخه را نمایش داده و سپس خارج می‌شود. این گزینه معادل گزینهٔ -showversion است، با این تفاوت که گزینهٔ دوم به JVM دستور خروج پس از نمایش اطلاعات نسخه را نمی‌دهد.

-version:release

نسخهٔ انتشار را برای اجرای برنامه مشخص می‌کند. اگر نسخهٔ دستور java فراخوانی‌شده با این مشخصه مطابقت نداشته باشد و پیاده‌سازی مناسبی روی سیستم پیدا شود، آنگاه پیاده‌سازی مناسب استفاده خواهد شد.

آرگومان release یا رشتهٔ نسخهٔ دقیق را مشخص می‌کند، یا فهرستی از رشته‌های نسخه و محدوده‌ها را که با فاصله از هم جدا شده‌اند. یک رشتهٔ نسخه تعیین شماره نسخه توسط توسعه‌دهنده به شکل زیر است: 1.x.0_u (که در آن x شماره نسخهٔ اصلی و u شماره نسخهٔ به‌روزرسانی است). یک محدودهٔ نسخه از یک رشتهٔ نسخه تشکیل شده است که به دنبال آن یک علامت بعلاوه (+) برای تعیین این نسخه یا نسخه‌های جدیدتر می‌آید، یا بخشی از رشتهٔ نسخه که به دنبال آن یک ستاره (*) برای تعیین هر رشتهٔ نسخه با پیشوند منطبق می‌آید. رشته‌ها و محدوده‌های نسخه می‌توانند با استفاده از فاصله برای ترکیب منطقی OR، یا علامت آمپرسند (&) برای ترکیب منطقی AND از دو رشته/محدودهٔ نسخه ترکیب شوند. به عنوان مثال، اگر اجرای کلاس یا فایل JAR نیازمند JRE 6u13 (1.6.0_13) یا هر نسخهٔ JRE 6 که از 6u10 (1.6.0_10) شروع می‌شود باشد، عبارت زیر را مشخص کنید:.sp

-version:"1.6.0_13 1.6* & 1.6.0_10+"
علامت‌های نقل‌قول تنها در صورتی لازم هستند که در پارامتر release فاصله وجود داشته باشد.

برای فایل‌های JAR، اولویت بر این است که نیازمندی‌های نگارش به‌جای خط فرمان، در manifest فایل JAR مشخص شوند.

این گزینه‌ها، گزینه‌هایی با کاربرد عمومی هستند که مختص Java HotSpot Virtual Machine می‌باشند.

-X

راهنمای مربوط به تمام گزینه‌های -X موجود را نمایش می‌دهد.

-Xbatch

کامپایل در پس‌زمینه را غیرفعال می‌کند. به‌طور پیش‌فرض، JVM متد را به‌عنوان یک وظیفه پس‌زمینه کامپایل کرده و تا زمان پایان کامپایل پس‌زمینه، متد را در حالت مفسر اجرا می‌کند. پرچم -Xbatch کامپایل پس‌زمینه را غیرفعال می‌کند تا کامپایل همه متدها به‌عنوان یک وظیفه پیش‌زمینه تا زمان تکمیل ادامه یابد.

این گزینه معادل -XX:-BackgroundCompilation است.

-Xbootclasspath:path

فهرستی از دایرکتوری‌ها، فایل‌های JAR و آرشیوهای ZIP جداشده با دونقطه (:) را برای جستجوی فایل‌های کلاس boot مشخص می‌کند. این موارد به‌جای فایل‌های کلاس boot موجود در JDK استفاده می‌شوند.

برنامه‌هایی را که از این گزینه برای بازنویسی یک کلاس در rt.jar استفاده می‌کنند مستقر نکنید، زیرا این کار مجوز کد باینری JRE را نقض می‌کند.

-Xbootclasspath/a:path

فهرستی از دایرکتوری‌ها، فایل‌های JAR و آرشیوهای ZIP جداشده با دونقطه (:) را برای افزودن به انتهای مسیر کلاس bootstrap پیش‌فرض مشخص می‌کند.

برنامه‌هایی را که از این گزینه برای بازنویسی یک کلاس در rt.jar استفاده می‌کنند مستقر نکنید، زیرا این کار مجوز کد باینری JRE را نقض می‌کند.

-Xbootclasspath/p:path

فهرستی از دایرکتوری‌ها، فایل‌های JAR و آرشیوهای ZIP جداشده با دونقطه (:) را برای افزودن به ابتدای مسیر کلاس bootstrap پیش‌فرض مشخص می‌کند.

برنامه‌هایی را که از این گزینه برای بازنویسی یک کلاس در rt.jar استفاده می‌کنند مستقر نکنید، زیرا این کار مجوز کد باینری JRE را نقض می‌کند.

-Xcheck:jni

بررسی‌های تکمیلی را برای توابع Java Native Interface (JNI) انجام می‌دهد. به‌طور مشخص، پیش از پردازش درخواست JNI، پارامترهای ارسالی به تابع JNI و داده‌های محیط زمان اجرا را اعتبارسنجی می‌کند. هرگونه داده نامعتبر نشان‌دهنده مشکلی در کد بومی است و در چنین مواردی JVM با یک خطای غیرقابل‌جبران متوقف خواهد شد. هنگام استفاده از این گزینه، انتظار افت کارایی را داشته باشید.

-Xcomp

کامپایل متدها را در اولین فراخوانی اجباری می‌کند. به‌طور پیش‌فرض، Client VM (-client) تعداد ۱٬۰۰۰ فراخوانی تفسیری متد و Server VM (-server) تعداد ۱۰٬۰۰۰ فراخوانی تفسیری متد را برای جمع‌آوری اطلاعات جهت کامپایل بهینه انجام می‌دهند. تعیین گزینه -Xcomp فراخوانی‌های تفسیری متد را غیرفعال می‌کند تا سرعت کامپایل به بهای کاهش بهره‌وری افزایش یابد.

همچنین می‌توانید تعداد فراخوانی‌های تفسیری متد قبل از کامپایل را با استفاده از گزینه -XX:CompileThreshold تغییر دهید.

-Xdebug

هیچ کاری انجام نمی‌دهد. برای سازگاری با گذشته ارائه شده است.

-Xdiag

پیام‌های عیب‌یابی تکمیلی را نشان می‌دهد.

-Xfuture

بررسی‌های سخت‌گیرانه قالب class-file را فعال می‌کند که انطباق دقیق با مشخصات قالب class-file را اعمال می‌نمایند. به توسعه‌دهندگان توصیه می‌شود هنگام توسعه کدهای جدید از این پرچم استفاده کنند، چرا که بررسی‌های سخت‌گیرانه‌تر در نگارش‌های آینده به حالت پیش‌فرض تبدیل خواهند شد.

-Xint

برنامه را فقط در حالت تفسیری اجرا می‌کند. کامپایل به کد بومی غیرفعال شده و تمام bytecode توسط مفسر اجرا می‌شود. مزایای عملکردی ارائه‌شده توسط کامپایلر just in time (JIT) در این حالت وجود نخواهند داشت.

-Xinternalversion

اطلاعات دقیق‌تری از نگارش JVM نسبت به گزینه -version نمایش می‌دهد و سپس خارج می‌شود.

-Xloggc:filename

فایلی را تعیین می‌کند که اطلاعات تفصیلی رویدادهای GC باید برای ثبت وقایع به آن هدایت شوند. اطلاعات نوشته‌شده در این فایل شبیه خروجی -verbose:gc همراه با زمان سپری‌شده از اولین رویداد GC پیش از هر رویداد ثبت‌شده است. در صورتی که هر دو گزینه با یک دستور java داده شوند، گزینه -Xloggc بر -verbose:gc مقدم خواهد بود.

مثال:

-Xloggc:garbage-collection.log

-Xmaxjitcodesize=size

حداکثر اندازه حافظه موقت کد (code cache به بایت) را برای کدهای کامپایل‌شده توسط JIT مشخص می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مشخص کردن مگابایت، و g یا G را برای مشخص کردن گیگابایت اضافه کنید. حداکثر اندازه پیش‌فرض حافظه موقت کد ۲۴۰ مگابایت است؛ اگر کامپایل لایه‌ای را با گزینه -XX:-TieredCompilation غیرفعال کنید، اندازه پیش‌فرض ۴۸ مگابایت خواهد بود: 
-Xmaxjitcodesize=240m
این گزینه معادل -XX:ReservedCodeCacheSize است.

-Xmixed

تمام bytecode را به‌جز متدهای پرتکرار (hot methods) که به کد بومی کامپایل می‌شوند، توسط مفسر اجرا می‌کند.

-Xmnsize

اندازه اولیه و حداکثر اندازه heap (به بایت) را برای نسل جوان (nursery) تنظیم می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مشخص کردن مگابایت، و g یا G را برای مشخص کردن گیگابایت اضافه کنید..sp ناحیه نسل جوان (young generation) در heap برای اشیاء جدید استفاده می‌شود. فرآیند GC در این ناحیه بیشتر از سایر نواحی انجام می‌گیرد. اگر اندازه نسل جوان بیش از حد کوچک باشد، جمع‌آوری‌های زباله فرعی (minor garbage collections) متعددی انجام خواهد شد. اگر اندازه بسیار بزرگ باشد، تنها جمع‌آوری‌های زباله کامل (full garbage collections) اجرا می‌شوند که تکمیل آن‌ها ممکن است زمان زیادی ببرد. شرکت Oracle توصیه می‌کند که اندازه نسل جوان را بین یک‌دوم تا یک‌چهارم اندازه کل heap نگه دارید.

مثال‌های زیر نحوه تنظیم اندازه اولیه و بیشینه نسل جوان را روی ۲۵۶ مگابایت با استفاده از واحدهای مختلف نشان می‌دهند:

-Xmn256m
-Xmn262144k
-Xmn268435456
به جای استفاده از گزینه -Xmn جهت تنظیم هم‌زمان اندازه اولیه و بیشینه heap برای نسل جوان، می‌توانید از -XX:NewSize برای تنظیم اندازه اولیه و از -XX:MaxNewSize برای تنظیم بیشینه اندازه استفاده کنید.

-Xmssize

اندازه اولیه (به بایت) heap را تنظیم می‌کند. این مقدار باید مضربی از ۱۰۲۴ و بزرگ‌تر از ۱ مگابایت باشد. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مشخص کردن مگابایت، و g یا G را برای مشخص کردن گیگابایت اضافه کنید.

مثال‌های زیر نحوه تنظیم اندازه حافظه تخصیص‌یافته به ۶ مگابایت را با استفاده از واحدهای مختلف نشان می‌دهند:

-Xms6291456
-Xms6144k
-Xms6m
اگر این گزینه را تنظیم نکنید، اندازه اولیه به عنوان مجموع اندازه‌های تخصیص‌یافته برای نسل قدیم (old generation) و نسل جوان (young generation) تنظیم خواهد شد. اندازه اولیه heap برای نسل جوان را می‌توان با استفاده از گزینه -Xmn یا گزینه -XX:NewSize تنظیم کرد.

-Xmxsize

بیشینه اندازه (به بایت) استخر تخصیص حافظه را مشخص می‌کند. این مقدار باید مضربی از ۱۰۲۴ و بزرگ‌تر از ۲ مگابایت باشد. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مشخص کردن مگابایت، و g یا G را برای مشخص کردن گیگابایت اضافه کنید. مقدار پیش‌فرض در زمان اجرا بر اساس پیکربندی سیستم انتخاب می‌شود. برای استقرارهای سرور، -Xms و -Xmx اغلب روی مقداری یکسان تنظیم می‌شوند. بخش «Ergonomics» را در Java SE HotSpot Virtual Machine Garbage Collection Tuning Guide در نشانی http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html ببینید.

مثال‌های زیر نحوه تنظیم بیشینه اندازه مجاز حافظه تخصیص‌یافته به ۸۰ مگابایت را با استفاده از واحدهای مختلف نشان می‌دهند:

-Xmx83886080
-Xmx81920k
-Xmx80m
گزینه -Xmx معادل -XX:MaxHeapSize است.

-Xnoclassgc

جمع‌آوری زباله (GC) کلاس‌ها را غیرفعال می‌کند. این کار می‌تواند مقداری از زمان GC را صرفه‌جویی کرده و وقفه‌ها را در حین اجرای برنامه کاهش دهد.

هنگامی که -Xnoclassgc را در زمان راه‌اندازی تعیین می‌کنید، شیءهای کلاس در برنامه در طول GC دست‌نخورده باقی می‌مانند و همواره فعال در نظر گرفته می‌شوند. این امر می‌تواند منجر به اشغال دائم حافظه بیشتری شود که در صورت عدم دقت، استثنای کمبود حافظه (out of memory exception) ایجاد خواهد کرد.

-Xrs

استفاده از سیگنال‌های سیستم‌عامل توسط JVM را کاهش می‌دهد.

قلاب‌های خاموشی (Shutdown hooks) با اجرای کد پاک‌سازی کاربر (مانند بستن اتصالات پایگاه داده) در هنگام خاموش شدن، حتی در صورتی که JVM به طور ناگهانی پایان یابد، خاموش شدن منظم یک برنامه جاوا را ممکن می‌سازند.

ماشین مجازی JVM سیگنال‌ها را دریافت می‌کند تا قلاب‌های خاموشی را برای پایان‌های غیرمنتظره پیاده‌سازی کند. ماشین مجازی JVM از SIGHUP، SIGINT و SIGTERM برای آغاز اجرای قلاب‌های خاموشی استفاده می‌کند.

ماشین مجازی JVM از سازوکار مشابهی برای پیاده‌سازی قابلیت روکشی پشته‌های ریسه (thread dumps) به منظور اشکال‌زدایی استفاده می‌کند. ماشین مجازی JVM از SIGQUIT برای انجام thread dumpها بهره می‌برد.

برنامه‌هایی که JVM را در خود تعبیه می‌کنند، مکرراً نیاز دارند سیگنال‌هایی مانند SIGINT یا SIGTERM را به دام بیندازند که این می‌تواند منجر به تداخل با گرداننده‌های سیگنال JVM شود. گزینه -Xrs برای رفع این مشکل در دسترس است. هنگامی که -Xrs استفاده می‌شود، ماسک‌های سیگنال برای SIGINT، SIGTERM، SIGHUP و SIGQUIT توسط JVM تغییر داده نمی‌شوند و گرداننده‌های سیگنال برای این سیگنال‌ها نصب نمی‌گردند.

مشخص کردن -Xrs دو پیامد دارد:

•گرفتن thread dump از طریق SIGQUIT در دسترس نیست.
•کد کاربر مسئول فراخوانی قلاب‌های خاموشی است، برای نمونه با فراخوانی System.exit() در زمانی که JVM باید خاتمه یابد.

-Xshare:mode

حالت اشتراک‌گذاری داده‌های کلاس (CDS) را تعیین می‌کند. آرگومان‌های ممکن برای mode در این گزینه عبارتند از:

auto

در صورت امکان از CDS استفاده شود. این مقدار پیش‌فرض برای Java HotSpot 32-Bit Client VM است. on
استفاده از CDS را الزامی می‌کند. در صورتی که امکان استفاده از اشتراک‌گذاری داده‌های کلاس (class data sharing) وجود نداشته باشد، پیام خطایی چاپ کرده و خارج می‌شود.

off

از CDS استفاده نمی‌کند. این مقدار پیش‌فرض برای Java HotSpot 32-Bit Server VM،‏ Java HotSpot 64-Bit Client VM و Java HotSpot 64-Bit Server VM است.

dump

بایگانی CDS را به‌طور دستی تولید می‌کند. مسیر کلاس برنامه را همان‌طور که در "Setting the Class Path" شرح داده شده است مشخص کنید.

باید با هر انتشار جدید JDK، بایگانی CDS را مجدداً ایجاد کنید.

-XshowSettings:category

تنظیمات را نشان داده و ادامه می‌دهد. آرگومان‌های ممکن category برای این گزینه شامل موارد زیر است:

all

تمام دسته‌بندی‌های تنظیمات را نشان می‌دهد. این مقدار پیش‌فرض است.

locale

تنظیمات مربوط به تنظیمات محلی (locale) را نشان می‌دهد.

properties

تنظیمات مربوط به مشخصه‌های سیستم (system properties) را نشان می‌دهد.

vm

تنظیمات JVM را نشان می‌دهد.

-Xsssize

اندازه پشته ریسه (thread stack size) را (به بایت) تنظیم می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، g یا G را برای گیگابایت اضافه کنید. مقدار پیش‌فرض به بستر بستگی دارد:
•Linux/ARM (32-bit): 320 KB
•Linux/i386 (32-bit): 320 KB
•Linux/x64 (64-bit): 1024 KB
•OS X (64-bit): 1024 KB
•Oracle Solaris/i386 (32-bit): 320 KB
•Oracle Solaris/x64 (64-bit): 1024 KB

مثال‌های زیر اندازه پشته ریسه را در واحدهای مختلف روی 1024 KB تنظیم می‌کنند:

-Xss1m
-Xss1024k
-Xss1048576
این گزینه معادل -XX:ThreadStackSize است.

-Xusealtsigs

به جای SIGUSR1 و SIGUSR2 از سیگنال‌های جایگزین برای سیگنال‌های داخلی JVM استفاده می‌کند. این گزینه معادل -XX:+UseAltSigs است.

-Xverify:mode

حالت وارسی‌کننده بایت‌کد (bytecode verifier) را تنظیم می‌کند. وارسی بایت‌کد به عیب‌یابی برخی از مشکلات کمک می‌کند، اما سرباری نیز به برنامه در حال اجرا اضافه می‌کند. آرگومان‌های ممکن mode برای این گزینه شامل موارد زیر است:

none

بایت‌کد را وارسی نمی‌کند. این کار زمان راه‌اندازی و همچنین حفاظت ارائه‌شده توسط Java را کاهش می‌دهد.

remote

کلاس‌هایی را که توسط بارگذار کلاس راه‌انداز (bootstrap class loader) بارگذاری نشده‌اند وارسی می‌کند. اگر گزینه -Xverify را مشخص نکنید، این رفتار پیش‌فرض است.

all

تمام کلاس‌ها را وارسی می‌کند.

این گزینه‌ها رفتار زمان اجرای Java HotSpot VM را کنترل می‌کنند.

-XX:+DisableAttachMechanism

گزینه‌ای را فعال می‌کند که سازوکار اتصال ابزارها به JVM را غیرفعال می‌سازد. به‌طور پیش‌فرض، این گزینه غیرفعال است؛ به این معنی که سازوکار اتصال فعال بوده و می‌توانید از ابزارهایی مانند jcmd، jstack، jmap و jinfo استفاده کنید.

-XX:ErrorFile=filename

مسیر و نام فایلی را مشخص می‌کند که داده‌های خطا در زمان وقوع یک خطای غیرقابل‌جبران در آن نوشته می‌شوند. به‌طور پیش‌فرض، این فایل در دایرکتوری کاری جاری و با نام hs_err_pidpid.log ایجاد می‌شود که در آن pid شناسه فرایندی است که موجب بروز خطا شده است. مثال زیر نحوه تنظیم فایل لاگ پیش‌فرض را نشان می‌دهد (توجه داشته باشید که شناسه فرایند به‌صورت %p مشخص می‌شود): 
-XX:ErrorFile=./hs_err_pid%p.log
مثال زیر نحوه تنظیم لاگ خطا را روی /var/log/java/java_error.log نشان می‌دهد: 
-XX:ErrorFile=/var/log/java/java_error.log
اگر فایل نتواند در دایرکتوری مشخص‌شده ایجاد شود (به‌دلیل کمبود فضا، مشکل دسترسی‌ها، یا مساله‌ای دیگر)، در دایرکتوری موقت سیستم‌عامل ایجاد می‌شود. دایرکتوری موقت /tmp است.

-XX:+FailOverToOldVerifier

انتقال خودکار (failover) به وارسی‌کننده قدیمی را در زمان شکست بررسی‌کننده نوع جدید فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و برای کلاس‌هایی با نسخه بایت‌کد جدید نادیده گرفته می‌شود (یعنی غیرفعال در نظر گرفته می‌شود). می‌توانید آن را برای کلاس‌هایی با نسخه‌های قدیمی‌تر بایت‌کد فعال کنید.

-XX:LargePageSizeInBytes=size

در Solaris، حداکثر اندازه (بر حسب بایت) را برای صفحات بزرگ مورد استفاده در هیپ جاوا تنظیم می‌کند. آرگومان size باید توانی از ۲ باشد (۲، ۴، ۸، ۱۶، ...). حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مشخص کردن مگابایت، و g یا G را برای مشخص کردن گیگابایت اضافه کنید. به‌طور پیش‌فرض، اندازه روی ۰ تنظیم شده است، به این معنی که JVM اندازه صفحات بزرگ را به‌طور خودکار انتخاب می‌کند.

مثال زیر نحوه تنظیم اندازه صفحات بزرگ روی ۴ مگابایت (MB) را نشان می‌دهد:

-XX:LargePageSizeInBytes=4m

-XX:MaxDirectMemorySize=size

حداکثر اندازه کل (بر حسب بایت) تخصیص‌های بافر مستقیم New I/O (بسته java.nio) را تنظیم می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مشخص کردن مگابایت، و g یا G را برای مشخص کردن گیگابایت اضافه کنید. به‌طور پیش‌فرض، اندازه روی ۰ تنظیم شده است، به این معنی که JVM اندازه تخصیص‌های بافر مستقیم NIO را به‌طور خودکار انتخاب می‌کند.

مثال‌های زیر نحوه تنظیم اندازه NIO روی ۱۰۲۴ کیلوبایت با واحدهای مختلف را نشان می‌دهند:

-XX:MaxDirectMemorySize=1m
-XX:MaxDirectMemorySize=1024k
-XX:MaxDirectMemorySize=1048576

-XX:NativeMemoryTracking=mode

حالت ردیابی مصرف حافظه بومی (native memory) ماشین مجازی JVM را مشخص می‌کند. آرگومان‌های ممکن برای mode شامل موارد زیر است:

off

مصرف حافظه بومی JVM را ردیابی نکن. در صورتی که گزینه -XX:NativeMemoryTracking را مشخص نکنید، این رفتار پیش‌فرض است.

summary

تنها مصرف حافظه توسط زیرسیستم‌های JVM نظیر هیپ جاوا، کلاس، کد و thread را ردیابی کن.

detail

علاوه بر ردیابی مصرف حافظه توسط زیرسیستم‌های JVM، مصرف حافظه توسط تک‌تک CallSiteها، نواحی منفرد حافظه مجازی و نواحی ثبت‌شده (committed) آن را نیز ردیابی کن.

-XX:ObjectAlignmentInBytes=alignment

تراز حافظه اشیاء جاوا را (بر حسب بایت) تنظیم می‌کند. به‌طور پیش‌فرض، مقدار روی ۸ بایت تنظیم شده است. مقدار مشخص‌شده باید توانی از ۲ باشد و باید در محدوده بین ۸ تا ۲۵۶ (شامل هر دو) قرار گیرد. این گزینه امکان استفاده از اشاره‌گرهای فشرده (compressed pointers) را با اندازه‌های بزرگ هیپ جاوا فراهم می‌کند.

حد اندازه هیپ بر حسب بایت به‌صورت زیر محاسبه می‌شود:

4GB * ObjectAlignmentInBytes

نکته: با افزایش مقدار تراز، فضای بلااستفاده بین اشیاء نیز افزایش خواهد یافت. در نتیجه، ممکن است هیچ مزیتی از استفاده از اشاره‌گرهای فشرده با اندازه‌های بزرگ هیپ جاوا به دست نیاورید.

-XX:OnError=string

یک دستور سفارشی یا مجموعه‌ای از دستورهای جداشده با نقطه‌ویرگول را تعیین می‌کند تا در هنگام وقوع یک خطای غیرقابل‌جبران اجرا شوند. اگر رشته حاوی فاصله باشد، باید داخل علامت نقل‌قول قرار گیرد.

مثال زیر نشان می‌دهد چگونه می‌توان از گزینه -XX:OnError برای اجرای دستور gcore جهت ایجاد تصویر هسته (core image) استفاده کرد، و اشکال‌زدا برای اتصال به فرایند در صورت بروز خطای غیرقابل‌جبران راه‌اندازی می‌شود (علامت %p نشان‌دهنده فرایند جاری است):

-XX:OnError="gcore %p;dbx - %p"

-XX:OnOutOfMemoryError=string

یک دستور سفارشی یا مجموعه‌ای از دستورهای جداشده با نقطه‌ویرگول را تعیین می‌کند تا در اولین باری که یک استثنای OutOfMemoryError پرتاب می‌شود، اجرا شوند. اگر رشته حاوی فاصله باشد، باید داخل علامت نقل‌قول قرار گیرد. برای دیدن مثالی از رشته دستور، توضیحات گزینه -XX:OnError را ببینید. -XX:+PerfDataSaveToFile
در صورت فعال بودن، داده‌های دودویی jstat(1) را هنگام خروج برنامهٔ Java ذخیره می‌کند. این داده‌های دودویی در فایلی با نام hsperfdata_<pid> ذخیره می‌شوند، که در آن <pid> شناسهٔ فرایند برنامهٔ Java اجراشده است. از jstat برای نمایش داده‌های کارایی موجود در این فایل به صورت زیر استفاده کنید: 
jstat -class file:///<path>/hsperfdata_<pid>
jstat -gc file:///<path>/hsperfdata_<pid>

-XX:+PrintCommandLineFlags

چاپ پرچم‌های ارگونومیک انتخاب‌شدهٔ JVM که در خط فرمان آمده‌اند را فعال می‌کند. دانستن مقادیر ارگونومیک تنظیم‌شده توسط JVM، مانند اندازهٔ فضای heap و زباله‌روب (garbage collector) انتخاب‌شده، می‌تواند مفید باشد. به‌طور پیش‌فرض، این گزینه غیرفعال است و پرچم‌ها چاپ نمی‌شوند.

-XX:+PrintNMTStatistics

چاپ داده‌های گردآوری‌شدهٔ ردیابی حافظه بومی (native memory tracking) را هنگام خروج JVM، در صورتی که ردیابی حافظه بومی فعال باشد، فعال می‌کند (ببینید: -XX:NativeMemoryTracking). به‌طور پیش‌فرض، این گزینه غیرفعال است و داده‌های ردیابی حافظه بومی چاپ نمی‌شوند.

-XX:+RelaxAccessControlCheck

میزان بررسی‌های کنترل دسترسی در ارزیاب (verifier) را کاهش می‌دهد. به‌طور پیش‌فرض، این گزینه غیرفعال است، و برای کلاس‌هایی با نسخهٔ جدید بایت‌کد نادیده گرفته می‌شود (یعنی به عنوان غیرفعال با آن رفتار می‌شود). می‌توانید آن را برای کلاس‌هایی با نسخه‌های قدیمی‌تر بایت‌کد فعال کنید.

-XX:+ShowMessageBoxOnError

نمایش یک کادر پیام را هنگامی که JVM با خطای جبران‌ناپذیر مواجه می‌شود فعال می‌کند. این کار مانع از خروج JVM شده و فرایند را فعال نگه می‌دارد تا بتوانید یک دیباگر را به منظور بررسی علت خطا به آن متصل کنید. به‌طور پیش‌فرض، این گزینه غیرفعال است.

-XX:ThreadStackSize=size

اندازهٔ پشتهٔ ریسه (thread stack) را (به بایت) تنظیم می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، و g یا G را برای گیگابایت اضافه کنید. مقدار پیش‌فرض به بستر بستگی دارد:
•Linux/ARM (32-bit): 320 KB
•Linux/i386 (32-bit): 320 KB
•Linux/x64 (64-bit): 1024 KB
•OS X (64-bit): 1024 KB
•Oracle Solaris/i386 (32-bit): 320 KB
•Oracle Solaris/x64 (64-bit): 1024 KB

مثال‌های زیر نحوهٔ تنظیم اندازهٔ پشتهٔ ریسه را روی 1024 KB با واحدهای مختلف نشان می‌دهند:

-XX:ThreadStackSize=1m
-XX:ThreadStackSize=1024k
-XX:ThreadStackSize=1048576
این گزینه معادل -Xss است.

-XX:+TraceClassLoading

ردیابی کلاس‌ها را به هنگام بارگذاری آن‌ها فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و کلاس‌ها ردیابی نمی‌شوند.

-XX:+TraceClassLoadingPreorder

ردیابی تمام کلاس‌های بارگذاری‌شده را به ترتیبی که به آن‌ها ارجاع داده می‌شود فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و کلاس‌ها ردیابی نمی‌شوند.

-XX:+TraceClassResolution

ردیابی تفکیک‌های constant pool را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و تفکیک‌های constant pool ردیابی نمی‌شوند.

-XX:+TraceClassUnloading

ردیابی کلاس‌ها را به هنگام تخلیه شدن آن‌ها فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و کلاس‌ها ردیابی نمی‌شوند.

-XX:+TraceLoaderConstraints

ردیابی ثبت محدودیت‌های بارگذار (loader constraints) را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و ثبت محدودیت‌های بارگذار ردیابی نمی‌شود.

-XX:+UseAltSigs

استفاده از سیگنال‌های جایگزین را به جای SIGUSR1 و SIGUSR2 برای سیگنال‌های داخلی JVM فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و سیگنال‌های جایگزین استفاده نمی‌شوند. این گزینه معادل -Xusealtsigs است.

-XX:-UseBiasedLocking

استفاده از قفل‌گذاری بایاس‌شده (biased locking) را غیرفعال می‌کند. برخی برنامه‌ها با حجم قابل‌توجهی از همگام‌سازی‌های بدون رقابت، ممکن است با فعال بودن این پرچم افزایش سرعت چشمگیری داشته باشند، در حالی که برنامه‌هایی با الگوهای خاص قفل‌گذاری ممکن است کند شوند. برای اطلاعات بیشتر در مورد روش biased locking، مثال موجود در Java Tuning White Paper را در http://www.oracle.com/technetwork/java/tuning-139912.html#section4.2.5 مشاهده کنید..sp به‌طور پیش‌فرض، این گزینه فعال است.

-XX:-UseCompressedOops

استفاده از اشاره‌گرهای فشرده (compressed pointers) را غیرفعال می‌کند. به‌طور پیش‌فرض، این گزینه فعال است و هنگامی که اندازه Java heap کمتر از 32 GB باشد، از اشاره‌گرهای فشرده استفاده می‌شود. زمانی که این گزینه فعال باشد، ارجاعات شیء به‌جای اشاره‌گرهای ۶۴ بیتی به‌صورت آفست‌های ۳۲ بیتی نمایش داده می‌شوند که معمولاً عملکرد اجرای برنامه با اندازه Java heap کمتر از 32 GB را بهبود می‌بخشد. این گزینه فقط برای JVMهای ۶۴ بیتی کار می‌کند.

همچنین امکان استفاده از اشاره‌گرهای فشرده در زمانی که اندازه Java heap بیشتر از 32GB باشد نیز وجود دارد. گزینه -XX:ObjectAlignmentInBytes را ببینید.

-XX:+UseHugeTLBFS

این گزینه برای Linux معادل مشخص کردن -XX:+UseLargePages است. این گزینه به‌طور پیش‌فرض غیرفعال است. این گزینه همه صفحه‌های بزرگ (large pages) را از ابتدا و هنگام رزرو حافظه از پیش تخصیص می‌دهد؛ در نتیجه JVM نمی‌تواند نواحی حافظه صفحه‌های بزرگ را به‌طور پویا افزایش یا کاهش دهد؛ اگر این رفتار را می‌خواهید، گزینه -XX:UseTransparentHugePages را ببینید.

برای اطلاعات بیشتر، «Large Pages» را ببینید.

-XX:+UseLargePages

استفاده از حافظه با صفحه بزرگ (large page memory) را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و از حافظه صفحه بزرگ استفاده نمی‌شود.

برای اطلاعات بیشتر، «Large Pages» را ببینید.

-XX:+UseMembar

صدور membarها را در هنگام گذار وضعیت ریسه‌ها (thread state transitions) فعال می‌کند. این گزینه به‌طور پیش‌فرض روی تمامی پلتفرم‌ها به‌جز سرورهای ARM غیرفعال است، که در آن‌ها فعال می‌باشد. (توصیه می‌شود که این گزینه را در سرورهای ARM غیرفعال نکنید.)

-XX:+UsePerfData

قابلیت perfdata را فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است تا امکان نظارت بر JVM و آزمایش کارایی فراهم شود. غیرفعال کردن آن از ایجاد دایرکتوری‌های hsperfdata_userid جلوگیری می‌کند. برای غیرفعال کردن قابلیت perfdata، گزینه -XX:-UsePerfData را مشخص کنید.

-XX:+UseTransparentHugePages

در Linux، استفاده از صفحه‌های بزرگی را که می‌توانند به‌طور پویا رشد یا کاهش یابند فعال می‌کند. این گزینه به‌طور پیش‌فرض غیرفعال است. ممکن است با transparent huge pages دچار مشکلات کارایی شوید زیرا سیستم‌عامل برای ایجاد huge pages، صفحه‌های دیگر را جابه‌جا می‌کند؛ این گزینه صرفاً برای آزمایش ارائه شده است.

برای اطلاعات بیشتر، «Large Pages» را ببینید.

-XX:+AllowUserSignalHandlers

امکان نصب گرداننده‌های سیگنال (signal handlers) توسط برنامه را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و برنامه اجازه نصب گرداننده‌های سیگنال را ندارد.

این گزینه‌ها کامپایل پویای در زمان اجرا (JIT - Just-In-Time) انجام‌شده توسط Java HotSpot VM را کنترل می‌کنند.

-XX:+AggressiveOpts

استفاده از قابلیت‌های بهینه‌سازی تهاجمی کارایی را فعال می‌کند، که انتظار می‌رود در انتشار‌های آینده به پیش‌فرض تبدیل شوند. به‌طور پیش‌فرض، این گزینه غیرفعال است و از ویژگی‌های آزمایشی کارایی استفاده نمی‌شود.

-XX:AllocateInstancePrefetchLines=lines

تعداد خطوطی که باید جلوتر از اشاره‌گر تخصیص نمونه پیش‌واکشی (prefetch) شوند را تنظیم می‌کند. به‌طور پیش‌فرض، تعداد خطوط پیش‌واکشی روی 1 تنظیم شده است: 
-XX:AllocateInstancePrefetchLines=1
تنها Java HotSpot Server VM از این گزینه پشتیبانی می‌کند.

-XX:AllocatePrefetchDistance=size

اندازه (به بایت) مسافت پیش‌واکشی (prefetch distance) را برای تخصیص شیء تعیین می‌کند. حافظه‌ای که قرار است با مقدار اشیاء جدید نوشته شود، تا این مسافت با شروع از آدرس آخرین شیء تخصیص‌یافته پیش‌واکشی می‌شود. هر ریسه جاوا نقطه تخصیص مخصوص به خود را دارد.

مقادیر منفی نشان می‌دهند که مسافت پیش‌واکشی بر اساس پلتفرم انتخاب می‌شود. مقادیر مثبت، بایت‌های مورد نظر برای پیش‌واکشی هستند. برای مشخص کردن کیلوبایت حرف k یا K، برای مگابایت حرف m یا M، و برای گیگابایت حرف g یا G را ضمیمه کنید. مقدار پیش‌فرض روی -1 تنظیم شده است.

مثال زیر نحوه تنظیم مسافت پیش‌واکشی به 1024 بایت را نشان می‌دهد:

-XX:AllocatePrefetchDistance=1024
تنها Java HotSpot Server VM از این گزینه پشتیبانی می‌کند.

-XX:AllocatePrefetchInstr=instruction

دستور پیش‌واکشی را برای پیش‌واکشی جلوتر از اشاره‌گر تخصیص تنظیم می‌کند. تنها Java HotSpot Server VM از این گزینه پشتیبانی می‌کند. مقادیر ممکن از 0 تا 3 هستند. دستورالعمل‌های واقعی مربوط به این مقادیر به پلتفرم بستگی دارد. به‌طور پیش‌فرض، دستور پیش‌واکشی روی 0 تنظیم شده است: 
-XX:AllocatePrefetchInstr=0
تنها Java HotSpot Server VM از این گزینه پشتیبانی می‌کند.

-XX:AllocatePrefetchLines=lines

تعداد خطوط حافظه نهان (cache lines) را برای بارگذاری پس از آخرین تخصیص شیء با استفاده از دستورالعمل‌های پیش‌واکشی تولیدشده در کد کامپایل‌شده تعیین می‌کند. مقدار پیش‌فرض اگر آخرین شیء تخصیص‌یافته یک نمونه باشد 1، و اگر یک آرایه باشد 3 است.

مثال زیر نحوه تنظیم تعداد خطوط حافظه نهان بارگذاری‌شده روی 5 را نشان می‌دهد:

-XX:AllocatePrefetchLines=5
تنها Java HotSpot Server VM از این گزینه پشتیبانی می‌کند.

-XX:AllocatePrefetchStepSize=size

اندازه گام (به بایت) را برای دستورالعمل‌های پیش‌واکشی متوالی تنظیم می‌کند. برای مشخص کردن کیلوبایت حرف k یا K، برای مگابایت حرف m یا M، و برای گیگابایت حرف g یا G را ضمیمه کنید. به‌طور پیش‌فرض، اندازه گام روی 16 بایت تنظیم شده است: 
-XX:AllocatePrefetchStepSize=16
تنها Java HotSpot Server VM از این گزینه پشتیبانی می‌کند. -XX:AllocatePrefetchStyle=style
سبک کد تولید‌شده برای دستورالعمل‌های پیش‌واکشی را تنظیم می‌کند. آرگومان style یک عدد صحیح از 0 تا 3 است:

0

دستورالعمل‌های پیش‌واکشی تولید نشوند.

1

اجرای دستورالعمل‌های پیش‌واکشی پس از هر تخصیص حافظه. این مقدار پیش‌فرض است.

2

استفاده از اشاره‌گر واترمارکِ بلوک تخصیص محلی نخ (TLAB) برای تعیین زمان اجرای دستورالعمل‌های پیش‌واکشی.

3

استفاده از دستورالعمل BIS در SPARC برای پیش‌واکشی تخصیص.

تنها Java HotSpot Server VM از این گزینه پشتیبانی می‌کند.

-XX:+BackgroundCompilation

کامپایل در پس‌زمینه را فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن کامپایل در پس‌زمینه، -XX:-BackgroundCompilation را مشخص کنید (این کار معادل تعیین -Xbatch است).

-XX:CICompilerCount=threads

تعداد نخ‌های کامپایلر مورد استفاده برای کامپایل را تعیین می‌کند. به‌طور پیش‌فرض، تعداد نخ‌ها برای JVM سرور روی 2، برای JVM کلاینت روی 1 تنظیم شده است و در صورت استفاده از کامپایل چندمرحله‌ای (tiered compilation)، متناسب با تعداد هسته‌ها مقیاس‌پذیر می‌شود. مثال زیر نحوه تنظیم تعداد نخ‌ها روی 2 را نشان می‌دهد: 
-XX:CICompilerCount=2

-XX:CodeCacheMinimumFreeSpace=size

حداقل فضای خالی (به بایت) لازم برای کامپایل را تعیین می‌کند. برای نشان دادن کیلوبایت حرف k یا K، برای مگابایت حرف m یا M و برای گیگابایت حرف g یا G را اضافه کنید. هنگامی که فضای خالی کمتر از حداقل تعیین‌شده باقی بماند، کامپایل متوقف می‌شود. به‌طور پیش‌فرض، این گزینه روی 500 KB تنظیم شده است. مثال زیر نحوه تنظیم حداقل فضای خالی روی 1024 MB را نشان می‌دهد: 
-XX:CodeCacheMinimumFreeSpace=1024m

-XX:CompileCommand=command,method[,option]

دستوری را برای اجرا روی یک متد مشخص می‌کند. برای مثال، برای مستثنی کردن متد indexOf() از کلاس String از کامپایل شدن، از دستور زیر استفاده کنید: 
-XX:CompileCommand=exclude,java/lang/String.indexOf
توجه داشته باشید که نام کامل کلاس مشخص می‌شود، شامل تمام بسته‌ها و زیربسته‌ها که با یک خط مورب (/) از یکدیگر جدا شده‌اند. برای عملیات آسان‌تر برش و جای‌گذاری، همچنین می‌توان از قالب نام متد تولیدشده توسط گزینه‌های -XX:+PrintCompilation و -XX:+LogCompilation استفاده کرد: 
-XX:CompileCommand=exclude,java.lang.String::indexOf
اگر متد بدون امضا مشخص شود، دستور روی تمامی متدهای با نام مشخص‌شده اعمال خواهد شد. با این حال، می‌توانید امضای متد را نیز در قالب فایل کلاس مشخص کنید. در این حالت، باید آرگومان‌ها را درون علامت نقل‌قول قرار دهید، زیرا در غیر این صورت پوسته با نقطه‌ویرگول مانند پایان دستور رفتار می‌کند. برای مثال، اگر می‌خواهید تنها متد indexOf(String) از کلاس String از کامپایل شدن مستثنی شود، از دستور زیر استفاده کنید: 
-XX:CompileCommand="exclude,java/lang/String.indexOf,(Ljava/lang/String;)I"
همچنین می‌توانید از علامت ستاره (*) به عنوان نویسه عام برای نام‌های کلاس و متد استفاده کنید. برای مثال، برای مستثنی کردن تمام متدهای indexOf() در تمام کلاس‌ها از کامپایل شدن، از دستور زیر استفاده کنید: 
-XX:CompileCommand=exclude,*.indexOf
ویرگول‌ها و نقطه‌ها نام‌های مستعار برای فاصله‌ها هستند و ارسال دستورات کامپایلر را از طریق پوسته آسان‌تر می‌کنند. می‌توانید با قرار دادن کل آرگومان در علامت نقل‌قول و استفاده از فاصله به عنوان جداکننده، آرگومان‌ها را به -XX:CompileCommand ارسال کنید: 
-XX:CompileCommand="exclude java/lang/String indexOf"
توجه داشته باشید که کامپایلر JIT پس از تجزیه دستورات ارسال‌شده در خط فرمان با استفاده از گزینه‌های -XX:CompileCommand، دستورات را از فایل .hotspot_compiler می‌خواند. می‌توانید دستوراتی را به این فایل اضافه کنید یا با استفاده از گزینه -XX:CompileCommandFile فایل دیگری را مشخص نمایید.

برای افزودن چندین دستور، یا گزینه -XX:CompileCommand را چندین بار مشخص کنید، یا هر آرگومان را با جداکننده خط جدید (\n) جدا سازید. دستورات زیر در دسترس هستند:

break

تنظیم یک نقطه توقف (breakpoint) هنگام اشکال‌زدایی JVM برای توقف در ابتدای کامپایل متد مشخص‌شده.

compileonly

مستثنی کردن تمام متدها از کامپایل، به جز متد مشخص‌شده. به عنوان یک جایگزین، می‌توانید از گزینه -XX:CompileOnly استفاده کنید که امکان مشخص کردن چندین متد را فراهم می‌کند. dontinline
از درون‌خطی‌سازی (inlining) متد مشخص‌شده جلوگیری می‌کند.

exclude

متد مشخص‌شده را از کامپایل مستثنی می‌کند.

help

یک پیام راهنما برای گزینهٔ -XX:CompileCommand چاپ می‌کند.

inline

برای درون‌خطی‌سازی متد مشخص‌شده تلاش می‌کند.

log

ثبت وقایع (لاگ‌گیری) کامپایل (با گزینهٔ -XX:+LogCompilation) را برای تمام متدها به‌جز متد مشخص‌شده مستثنی (غیرفعال) می‌کند. به‌طور پیش‌فرض، ثبت وقایع برای تمام متدهای کامپایل‌شده انجام می‌شود.

option

از این دستور می‌توان برای ارسال یک گزینهٔ کامپایل JIT به متد مشخص‌شده به‌جای آخرین آرگومان (option) استفاده کرد. گزینهٔ کامپایل در پایان، پس از نام متد مشخص می‌شود. برای نمونه، جهت فعال‌سازی گزینهٔ BlockLayoutByFrequency برای متد append() از کلاس StringBuffer، از دستور زیر استفاده کنید: 
-XX:CompileCommand=option,java/lang/StringBuffer.append,BlockLayoutByFrequency
می‌توانید چندین گزینهٔ کامپایل را با کاما یا فاصله از یکدیگر جدا کرده و مشخص کنید.

print

کد اسمبلی تولیدشده را پس از کامپایل متد مشخص‌شده چاپ می‌کند.

quiet

دستورهای کامپایل را چاپ نمی‌کند. به‌طور پیش‌فرض، دستورهایی که با گزینهٔ -XX:CompileCommand مشخص می‌کنید چاپ می‌شوند؛ برای نمونه، اگر متد indexOf() از کلاس String را از کامپایل مستثنی کنید، عبارت زیر در خروجی استاندارد چاپ خواهد شد: 
CompilerOracle: exclude java/lang/String.indexOf
می‌توانید با مشخص کردن گزینهٔ -XX:CompileCommand=quiet پیش از سایر گزینه‌های -XX:CompileCommand، از چاپ این خروجی جلوگیری کنید.

-XX:CompileCommandFile=filename

فایلی را مشخص می‌کند که دستورهای کامپایلر JIT از آن خوانده می‌شوند. به‌طور پیش‌فرض، از فایل .hotspot_compiler برای ذخیرهٔ دستورهای اعمال‌شده توسط کامپایلر JIT استفاده می‌شود.

هر خط در فایل دستور بیانگر یک دستور، نام یک کلاس و نام متدی است که دستور برای آن به‌کار می‌رود. برای نمونه، این خط کد اسمبلی را برای متد toString() از کلاس String چاپ می‌کند:

print java/lang/String toString
برای اطلاعات بیشتر دربارهٔ نحوهٔ مشخص کردن دستورها برای اجرا روی متدها توسط کامپایلر JIT، گزینهٔ -XX:CompileCommand را ببینید.

-XX:CompileOnly=methods

فهرستی از متدها (جداشده با کاما) را تعیین می‌کند که کامپایل باید به آن‌ها محدود شود. تنها متدهای مشخص‌شده کامپایل خواهند شد. هر متد را با نام کامل کلاس (شامل بسته‌ها و زیربسته‌ها) مشخص کنید. برای نمونه، برای کامپایل انحصاری متد length() از کلاس String و متد size() از کلاس List، از دستور زیر استفاده کنید: 
-XX:CompileOnly=java/lang/String.length,java/util/List.size
توجه داشته باشید که نام کامل کلاس مشخص شده است که شامل تمام بسته‌ها و زیربسته‌ها می‌شود که با اسلش (/) از یکدیگر جدا شده‌اند. برای ساده‌تر شدن عملیات برش و چسباندن (cut and paste)، همچنین امکان استفاده از قالب نام متد تولیدشده توسط گزینه‌های -XX:+PrintCompilation و -XX:+LogCompilation وجود دارد: 
-XX:CompileOnly=java.lang.String::length,java.util.List::size
اگرچه نویسه‌های عمومی (wildcardها) پشتیبانی نمی‌شوند، اما می‌توانید تنها نام کلاس یا بسته را مشخص کنید تا تمام متدهای آن کلاس یا بسته کامپایل شوند، و همچنین می‌توانید صرفاً نام متد را مشخص کنید تا متدهای دارای این نام در هر کلاسی کامپایل شوند: 
-XX:CompileOnly=java/lang/String
-XX:CompileOnly=java/lang
-XX:CompileOnly=.length

-XX:CompileThreshold=invocations

تعداد فراخوانی‌های تفسیرشدهٔ متد را پیش از آغاز کامپایل تعیین می‌کند. به‌طور پیش‌فرض در JVM سرور، کامپایلر JIT تعداد ۱۰٬۰۰۰ فراخوانی تفسیرشدهٔ متد را به‌منظور گردآوری اطلاعات جهت کامپایل بهینه انجام می‌دهد. برای JVM کلاینت، مقدار پیش‌فرض ۱٬۵۰۰ فراخوانی است. در صورت فعال بودن کامپایل لایه‌ای (tiered compilation)، این گزینه نادیده گرفته می‌شود؛ گزینهٔ -XX:+TieredCompilation را ببینید. مثال زیر نحوهٔ تنظیم تعداد فراخوانی‌های متد تفسیرشده را به ۵٬۰۰۰ نشان می‌دهد: 
-XX:CompileThreshold=5000
می‌توانید با مشخص کردن گزینهٔ -Xcomp، تفسیر متدهای جاوا را پیش از کامپایل به‌طور کامل غیرفعال کنید. -XX:+DoEscapeAnalysis
استفاده از تحلیل گریز (escape analysis) را فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن استفاده از تحلیل گریز، گزینهٔ -XX:-DoEscapeAnalysis را مشخص کنید. فقط Java HotSpot Server VM از این گزینه پشتیبانی می‌کند.

-XX:InitialCodeCacheSize=size

اندازهٔ اولیهٔ حافظهٔ نهان کد (code cache) را به بایت تنظیم می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، و g یا G را برای گیگابایت اضافه کنید. مقدار پیش‌فرض روی 500 کیلوبایت تنظیم شده است. اندازهٔ اولیهٔ حافظهٔ نهان کد نباید کمتر از حداقل اندازهٔ صفحهٔ حافظه در سیستم باشد. مثال زیر نحوهٔ تنظیم اندازهٔ اولیهٔ حافظهٔ نهان کد روی ۳۲ کیلوبایت را نشان می‌دهد: 
-XX:InitialCodeCacheSize=32k

-XX:+Inline

درون‌خطی‌سازی متدها (method inlining) را فعال می‌کند. این گزینه به‌منظور افزایش کارایی به‌طور پیش‌فرض فعال است. برای غیرفعال کردن درون‌خطی‌سازی متدها، گزینهٔ -XX:-Inline را مشخص کنید.

-XX:InlineSmallCode=size

حداکثر اندازهٔ کد (به بایت) را برای متدهای کامپایل‌شده‌ای که باید درون‌خطی شوند تنظیم می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، و g یا G را برای گیگابایت اضافه کنید. تنها متدهای کامپایل‌شده‌ای که اندازه‌شان از اندازهٔ تعیین‌شده کوچکتر باشد درون‌خطی خواهند شد. به‌طور پیش‌فرض، حداکثر اندازهٔ کد روی ۱۰۰۰ بایت تنظیم شده است: 
-XX:InlineSmallCode=1000

-XX:+LogCompilation

ثبت لاگ فعالیت‌های کامپایل را در فایلی با نام hotspot.log در دایرکتوری کاری فعلی فعال می‌کند. می‌توانید با استفاده از گزینهٔ -XX:LogFile مسیر و نام فایل لاگ متفاوتی را مشخص کنید.

به‌طور پیش‌فرض، این گزینه غیرفعال است و فعالیت کامپایل ثبت نمی‌شود. گزینهٔ -XX:+LogCompilation باید همراه با گزینهٔ -XX:UnlockDiagnosticVMOptions که گزینه‌های تشخیصی JVM را فعال می‌کند، استفاده شود.

می‌توانید با استفاده از گزینهٔ -XX:+PrintCompilation خروجی تشخیصی پرجزئیات را فعال کنید تا با هر بار کامپایل شدن یک متد، پیامی در کنسول چاپ شود.

-XX:MaxInlineSize=size

حداکثر اندازهٔ بایت‌کد (به بایت) یک متد برای درون‌خطی شدن را تعیین می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، و g یا G را برای گیگابایت اضافه کنید. به‌طور پیش‌فرض، حداکثر اندازهٔ بایت‌کد روی ۳۵ بایت تنظیم شده است: 
-XX:MaxInlineSize=35

-XX:MaxNodeLimit=nodes

حداکثر تعداد گره‌های مورد استفاده در طول کامپایل یک متد منفرد را تنظیم می‌کند. به‌طور پیش‌فرض، حداکثر تعداد گره‌ها روی ۶۵٬۰۰۰ تنظیم شده است: 
-XX:MaxNodeLimit=65000

-XX:MaxTrivialSize=size

حداکثر اندازهٔ بایت‌کد (به بایت) یک متد ناچیز (trivial method) را برای درون‌خطی شدن تنظیم می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، و g یا G را برای گیگابایت اضافه کنید. به‌طور پیش‌فرض، حداکثر اندازهٔ بایت‌کد یک متد ناچیز روی ۶ بایت تنظیم شده است: 
-XX:MaxTrivialSize=6

-XX:+OptimizeStringConcat

بهینه‌سازی عملیات الحاق String را فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن بهینه‌سازی عملیات الحاق String، گزینهٔ -XX:-OptimizeStringConcat را مشخص کنید. فقط Java HotSpot Server VM از این گزینه پشتیبانی می‌کند.

-XX:+PrintAssembly

چاپ کد اسمبلی را برای متدهای بومی (native) و بایت‌کدی با استفاده از کتابخانهٔ خارجی disassembler.so فعال می‌کند. این ویژگی امکان مشاهدهٔ کد تولیدشده را فراهم می‌سازد که می‌تواند به تشخیص مشکلات کارایی کمک کند.

به‌طور پیش‌فرض، این گزینه غیرفعال است و کد اسمبلی چاپ نمی‌شود. گزینهٔ -XX:+PrintAssembly باید همراه با گزینهٔ -XX:UnlockDiagnosticVMOptions که گزینه‌های تشخیصی JVM را فعال می‌کند، استفاده شود. -XX:+PrintCompilation

خروجی تشخیصی پرگو (verbose) از JVM را با چاپ یک پیام در کنسول هنگام کامپایل شدن هر متد، فعال می‌کند. این قابلیت به شما امکان می‌دهد ببینید دقیقاً چه متدهایی کامپایل می‌شوند. به‌طور پیش‌فرض، این گزینه غیرفعال است و خروجی تشخیصی چاپ نمی‌شود.

همچنین می‌توانید فعالیت‌های کامپایل را با استفاده از گزینهٔ -XX:+LogCompilation در یک فایل ثبت کنید.

-XX:+PrintInlining

چاپ تصمیمات مربوط به درون‌خطی‌سازی (inlining) را فعال می‌کند. این قابلیت به شما امکان می‌دهد ببینید کدام متدها درون‌خطی می‌شوند.

به‌طور پیش‌فرض، این گزینه غیرفعال است و اطلاعات درون‌خطی‌سازی چاپ نمی‌شود. گزینهٔ -XX:+PrintInlining باید همراه با گزینهٔ -XX:+UnlockDiagnosticVMOptions استفاده شود که گزینه‌های تشخیصی JVM را بازگشایی می‌کند.

-XX:ReservedCodeCacheSize=size

حداکثر اندازهٔ کَش کد (code cache به بایت) را برای کدهای کامپایل‌شده توسط JIT تعیین می‌کند. برای مشخص کردن کیلوبایت، حرف k یا K، برای مگابایت، حرف m یا M، و برای گیگابایت، حرف g یا G را اضافه کنید. حداکثر اندازهٔ پیش‌فرض کَش کد ۲۴۰ مگابایت است؛ اگر کامپایل چندسطحی (tiered compilation) را با گزینهٔ -XX:-TieredCompilation غیرفعال کنید، اندازهٔ پیش‌فرض ۴۸ مگابایت خواهد بود. این گزینه دارای محدودیت ۲ گیگابایت است؛ در غیر این صورت خطا تولید می‌شود. حداکثر اندازهٔ کَش کد نباید کمتر از اندازهٔ اولیهٔ کَش کد باشد؛ به گزینهٔ -XX:InitialCodeCacheSize مراجعه کنید. این گزینه معادل -Xmaxjitcodesize است.

-XX:RTMAbortRatio=abort_ratio

نسبت لغو RTM به‌صورت درصدی (٪) از تمام تراکنش‌های اجراشدهٔ RTM مشخص می‌شود. اگر تعداد تراکنش‌های لغوشده از این نسبت بیشتر شود، کد کامپایل‌شده از حالت بهینه‌سازی خارج (deoptimize) خواهد شد. این نسبت زمانی استفاده می‌شود که گزینهٔ -XX:+UseRTMDeopt فعال باشد. مقدار پیش‌فرض این گزینه ۵۰ است. این بدان معناست که در صورت لغو شدن ۵۰٪ از کل تراکنش‌ها، کد کامپایل‌شده deoptimize می‌شود.

-XX:RTMRetryCount=number_of_retries

کد قفل‌گذاری RTM هنگام لغو شدن یا اشغال بودن، به تعداد دفعاتی که توسط این گزینه تعیین شده تلاش مجدد می‌کند و سپس به سازوکار قفل‌گذاری عادی بازمی‌گردد (fallback). مقدار پیش‌فرض این گزینه ۵ است. گزینهٔ -XX:UseRTMLocking باید فعال باشد.

-XX:-TieredCompilation

استفاده از کامپایل چندسطحی (tiered compilation) را غیرفعال می‌کند. به‌طور پیش‌فرض، این گزینه فعال است. تنها Java HotSpot Server VM از این گزینه پشتیبانی می‌کند.

-XX:+UseAES

توابع درونی (intrinsics) مبتنی بر سخت‌افزار AES را برای سخت‌افزارهای Intel، AMD و SPARC فعال می‌کند. سخت‌افزارهای Intel Westmere (سال ۲۰۱۰ و جدیدتر)، AMD Bulldozer (سال ۲۰۱۱ و جدیدتر) و SPARC (مدل T4 و جدیدتر) پشتیبانی می‌شوند. UseAES در ترکیب با UseAESIntrinsics استفاده می‌شود.

-XX:+UseAESIntrinsics

پرچم‌های UseAES و UseAESIntrinsics به‌طور پیش‌فرض فعال هستند و تنها در نسخه‌های ۳۲ بیتی و ۶۴ بیتی Java HotSpot Server VM پشتیبانی می‌شوند. برای غیرفعال کردن توابع درونی سخت‌افزاری AES، عبارت -XX:-UseAES -XX:-UseAESIntrinsics را مشخص کنید. برای نمونه، جهت فعال‌سازی سخت‌افزاری AES، از پرچم‌های زیر استفاده کنید: 
-XX:+UseAES -XX:+UseAESIntrinsics
جهت پشتیبانی از پرچم‌های UseAES و UseAESIntrinsics برای نسخه‌های ۳۲ بیتی و ۶۴ بیتی، از گزینهٔ -server برای انتخاب Java HotSpot Server VM استفاده کنید. این پرچم‌ها در Client VM پشتیبانی نمی‌شوند.

-XX:+UseCodeCacheFlushing

تخلیهٔ کَش کد را پیش از خاموش شدن کامپایلر فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن تخلیهٔ کَش کد پیش از خاموش شدن کامپایلر، -XX:-UseCodeCacheFlushing را مشخص کنید.

-XX:+UseCondCardMark

بررسی علامت‌گذاری پیشین کارت را قبل از به‌روزرسانی جدول کارت (card table) فعال می‌کند. این گزینه به‌طور پیش‌فرض غیرفعال است و تنها باید در ماشین‌های چندسوکت استفاده شود؛ در چنین سیستم‌هایی کارایی برنامه‌های جاوا که به‌شدت بر عملیات همروند متکی هستند را افزایش می‌دهد. تنها Java HotSpot Server VM از این گزینه پشتیبانی می‌کند.

-XX:+UseRTMDeopt

قفل‌گذاری RTM را بر اساس نسبت لغو (abort ratio) به‌طور خودکار تنظیم می‌کند. این نسبت توسط گزینهٔ -XX:RTMAbortRatio تعیین می‌شود. اگر تعداد تراکنش‌های لغوشده از نسبت لغو فراتر رود، متد شامل قفل deoptimize شده و با تبدیل همهٔ قفل‌ها به قفل‌های عادی مجدداً کامپایل می‌شود. این گزینه به‌طور پیش‌فرض غیرفعال است. گزینهٔ -XX:+UseRTMLocking باید فعال باشد.

-XX:+UseRTMLocking

کد قفل‌گذاری حافظهٔ تراکنشی محدود (RTM) را برای تمام قفل‌های متورم‌شده (inflated locks) با در نظر گرفتن سازوکار قفل‌گذاری عادی به عنوان راه‌حل بازگشتی (fallback handler) تولید می‌کند. این گزینه به‌طور پیش‌فرض غیرفعال است. گزینه‌های مربوط به RTM تنها برای Java HotSpot Server VM روی پردازنده‌های x86 که از Transactional Synchronization Extensions (TSX) پشتیبانی می‌کنند در دسترس هستند.

ویژگی RTM بخشی از اینتل TSX است که یک توسعهٔ مجموعه دستورالعمل x86 محسوب می‌شود و ایجاد برنامه‌های چندرشته‌ای را تسهیل می‌کند. ویژگی RTM دستورالعمل‌های جدید XBEGIN، XABORT، XEND و XTEST را معرفی می‌کند. دستورالعمل‌های XBEGIN و XEND مجموعه‌ای از دستورالعمل‌ها را احاطه می‌کنند تا به‌صورت یک تراکنش اجرا شوند. اگر در زمان اجرای تراکنش هیچ تداخلی رخ ندهد، تغییرات حافظه و ثبات‌ها هم‌زمان در دستورالعمل XEND تثبیت (commit) می‌شوند. از دستورالعمل XABORT می‌توان برای لغو صریح یک تراکنش و از دستورالعمل XEND برای بررسی اینکه آیا مجموعه‌ای از دستورالعمل‌ها در قالب یک تراکنش اجرا می‌شوند یا خیر استفاده کرد.

قفل روی یک تراکنش زمانی متورم می‌شود که رشتهٔ دیگری تلاش کند به همان تراکنش دسترسی پیدا کند، و در نتیجه رشته‌ای را که در ابتدا درخواست دسترسی به تراکنش را نداشته است مسدود می‌کند. سازوکار RTM نیازمند تعیین مجموعه‌ای از عملیات جایگزین (fallback) برای شرایط لغو یا شکست تراکنش است. قفل RTM قفلی است که به سیستم TSX واگذار شده است.

ویژگی RTM کارایی قفل‌های با رقابت بالا (highly contended) و تداخل کم را در یک ناحیهٔ بحرانی (کدی که نباید بیش از یک رشته به‌طور هم‌روند به آن دسترسی داشته باشد) بهبود می‌بخشد. همچنین RTM عملکرد قفل‌گذاری درشت‌دانه (coarse-grain locking) را که معمولاً در برنامه‌های چندرشته‌ای عملکرد مطلوبی ندارد، ارتقا می‌دهد. (قفل‌گذاری درشت‌دانه راهبردی است که در آن قفل‌ها برای مدت طولانی نگه داشته می‌شوند تا سربار گرفتن و آزادسازی قفل به حداقل برسد، در حالی که قفل‌گذاری ریزدانه استراتژی دستیابی به حداکثر موازی‌سازی با قفل کردن فقط در زمان لزوم و باز کردن آن در سریع‌ترین زمان ممکن است.) همچنین برای قفل‌های با رقابت کم که توسط رشته‌های متفاوتی استفاده می‌شوند، RTM می‌تواند اشتراک‌گذاری کاذب خط کَش (false cache line sharing) را که با نام پینگ‌پنگ خط کَش نیز شناخته می‌شود، کاهش دهد. این حالت زمانی رخ می‌دهد که چندین رشته از پردازنده‌های مختلف به منابع گوناگونی دسترسی دارند، اما آن منابع در یک خط کَش مشترک قرار دارند. در نتیجه، پردازنده‌ها مکرراً خطوط کَش پردازنده‌های دیگر را باطل می‌کنند که آن‌ها را مجبور به خواندن داده‌ها از حافظهٔ اصلی به جای کَش می‌کند.

-XX:+UseSHA

توابع درونی (intrinsics) مبتنی بر سخت‌افزار را برای توابع هش رمزنگاری SHA در سخت‌افزار SPARC فعال می‌کند. UseSHA در ترکیب با گزینه‌های UseSHA1Intrinsics، UseSHA256Intrinsics و UseSHA512Intrinsics استفاده می‌شود.

پرچم‌های UseSHA و UseSHA*Intrinsics به‌طور پیش‌فرض فعال هستند و تنها برای Java HotSpot Server VM نسخهٔ ۶۴ بیتی روی SPARC T4 و جدیدتر پشتیبانی می‌شوند.

این ویژگی تنها در صورت استفاده از ارائه‌دهندهٔ sun.security.provider.Sun برای عملیات SHA قابل اعمال است.

برای غیرفعال کردن تمام توابع درونی سخت‌افزاری SHA، -XX:-UseSHA را مشخص کنید. برای غیرفعال کردن یک تابع درونی خاص SHA، از گزینهٔ متناظر مناسب استفاده کنید. برای مثال: -XX:-UseSHA256Intrinsics.

-XX:+UseSHA1Intrinsics

توابع درونی را برای تابع هش رمزنگاری SHA-1 فعال می‌کند.

-XX:+UseSHA256Intrinsics

توابع درونی را برای توابع هش رمزنگاری SHA-224 و SHA-256 فعال می‌کند.

-XX:+UseSHA512Intrinsics

توابع درونی را برای توابع هش رمزنگاری SHA-384 و SHA-512 فعال می‌کند.

-XX:+UseSuperWord

تبدیل عملیات اسکالر (scalar) به عملیات ابرکلمه (superword) را فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن تبدیل عملیات اسکالر به ابرکلمه، -XX:-UseSuperWord را مشخص کنید. تنها Java HotSpot Server VM از این گزینه پشتیبانی می‌کند.

این گزینه‌ها امکان جمع‌آوری اطلاعات سیستم و انجام اشکال‌زدایی گسترده را فراهم می‌کنند.

-XX:+ExtendedDTraceProbes

کاوشگرهای (probe) اضافی ابزار dtrace را که بر کارایی تأثیر می‌گذارند، فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و dtrace تنها کاوشگرهای استاندارد را اجرا می‌کند.

-XX:+HeapDumpOnOutOfMemory

تخلیه یا دامپ حافظه هیپ (heap) جاوا را در فایلی در دایرکتوری جاری با استفاده از پروفایلر هیپ (HPROF) در زمان پرتاب استثنای java.lang.OutOfMemoryError فعال می‌کند. می‌توانید مسیر و نام فایل دامپ هیپ را با استفاده از گزینه -XX:HeapDumpPath به صورت صریح تعیین کنید. به‌طور پیش‌فرض، این گزینه غیرفعال است و هنگام رخ دادن استثنای OutOfMemoryError هیپ ذخیره نمی‌شود.

-XX:HeapDumpPath=path

مسیر و نام فایل را برای نوشتن دامپ هیپ ارائه‌شده توسط پروفایلر هیپ (HPROF) هنگام فعال بودن گزینه -XX:+HeapDumpOnOutOfMemoryError تعیین می‌کند. به‌طور پیش‌فرض، این فایل در دایرکتوری کاری جاری ایجاد می‌شود و نام آن java_pidpid.hprof است که در آن pid شناسه فرایندی است که موجب بروز خطا شده است. مثال زیر نحوه تنظیم صریح فایل پیش‌فرض را نشان می‌دهد (%p نشان‌دهنده شناسه فرایند جاری است): 
-XX:HeapDumpPath=./java_pid%p.hprof
مثال زیر نحوه تنظیم فایل دامپ هیپ به /var/log/java/java_heapdump.hprof را نشان می‌دهد: 
-XX:HeapDumpPath=/var/log/java/java_heapdump.hprof

-XX:LogFile=path

مسیر و نام فایلی که داده‌های لاگ در آن نوشته می‌شوند را تعیین می‌کند. به‌طور پیش‌فرض، فایل در دایرکتوری کاری جاری ایجاد می‌شود و نام آن hotspot.log است.

مثال زیر نحوه تعیین فایل لاگ به /var/log/java/hotspot.log را نشان می‌دهد:

-XX:LogFile=/var/log/java/hotspot.log

-XX:+PrintClassHistogram

چاپ هیستوگرام نمونه‌های کلاس را پس از یک رویداد Control+C (SIGTERM) فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است.

تنظیم این گزینه معادل اجرای دستور jmap -histo یا دستور jcmd pid GC.class_histogram است، که در آن pid شناسه فرایند جاوای جاری است.

-XX:+PrintConcurrentLocks

چاپ قفل‌ها را پس از یک رویداد فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است.

چاپ قفل‌های java.util.concurrent را پس از یک رویداد Control+C (SIGTERM) فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است.

تنظیم این گزینه معادل اجرای دستور jstack -l یا دستور jcmd pid Thread.print -l است، که در آن pid شناسه فرایند جاوای جاری است.

-XX:+UnlockDiagnosticVMOptions

گزینه‌های در نظر گرفته شده برای عیب‌یابی و ارزیابی JVM را بازگشایی می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و گزینه‌های عیب‌یابی در دسترس نیستند.

این گزینه‌ها نحوهٔ انجام بازیافت حافظه (GC) را توسط Java HotSpot VM کنترل می‌کنند.

-XX:+AggressiveHeap

بهینه‌سازی هیپ جاوا را فعال می‌کند. این گزینه پارامترهای مختلف را بر اساس پیکربندی رایانه (RAM و CPU) به‌گونه‌ای بهینه می‌کند که برای کارهای طولانی‌مدت با تخصیص حافظهٔ سنگین مناسب باشند. به‌طور پیش‌فرض، این گزینه غیرفعال است و هیپ بهینه‌سازی نمی‌شود.

-XX:+AlwaysPreTouch

لمس (touching) تمام صفحه‌ها در هیپ جاوا را هنگام مقداردهی اولیهٔ JVM فعال می‌کند. این کار تمام صفحه‌ها را پیش از ورود به متد main() وارد حافظه می‌کند. این گزینه می‌تواند در آزمایش‌ها برای شبیه‌سازی سیستمی طولانی‌مدت که در آن تمام حافظهٔ مجازی به حافظهٔ فیزیکی نگاشت شده است، استفاده شود. به‌طور پیش‌فرض، این گزینه غیرفعال است و تمام صفحه‌ها با پر شدن فضای هیپ JVM تخصیص داده (commit) می‌شوند.

-XX:+CMSClassUnloadingEnabled

تخلیهٔ کلاس‌ها (class unloading) را هنگام استفاده از بازیافت‌کنندهٔ حافظهٔ concurrent mark-sweep (CMS) فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن تخلیهٔ کلاس‌ها برای بازیافت‌کنندهٔ حافظهٔ CMS، گزینهٔ -XX:-CMSClassUnloadingEnabled را مشخص کنید.

-XX:CMSExpAvgFactor=percent

درصد زمانی (0 تا 100) را که برای وزن‌دهی به نمونهٔ فعلی هنگام محاسبهٔ میانگین‌های نمایی برای آمارهای گردآوری هم‌روند استفاده می‌شود، تنظیم می‌کند. به‌طور پیش‌فرض، ضریب میانگین‌های نمایی روی 25% تنظیم شده است. مثال زیر نحوهٔ تنظیم این ضریب روی 15% را نشان می‌دهد: 
-XX:CMSExpAvgFactor=15

-XX:CMSInitiatingOccupancyFraction=percent

درصد اشغال نسل قدیمی (0 تا 100) را که در آن چرخهٔ گردآوری CMS آغاز می‌شود، تعیین می‌کند. مقدار پیش‌فرض روی -1 تنظیم شده است. هر مقدار منفی (شامل مقدار پیش‌فرض) به این معناست که -XX:CMSTriggerRatio برای تعریف مقدار کسر اشغال آغازین استفاده می‌شود.

مثال زیر نحوهٔ تنظیم کسر اشغال روی 20% را نشان می‌دهد:

-XX:CMSInitiatingOccupancyFraction=20

-XX:+CMSScavengeBeforeRemark

تلاش‌های روبش (scavenging) را پیش از مرحلهٔ remark در CMS فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است.

-XX:CMSTriggerRatio=percent

درصدی (0 تا 100) از مقدار مشخص‌شده توسط -XX:MinHeapFreeRatio را که پیش از آغاز چرخهٔ گردآوری CMS تخصیص می‌یابد، تنظیم می‌کند. مقدار پیش‌فرض روی 80% تنظیم شده است.

مثال زیر نحوهٔ تنظیم کسر اشغال روی 75% را نشان می‌دهد:

-XX:CMSTriggerRatio=75

-XX:ConcGCThreads=threads

تعداد نخ‌های مورد استفاده برای GC هم‌روند را تنظیم می‌کند. مقدار پیش‌فرض به تعداد پردازنده‌های (CPU) در دسترس JVM بستگی دارد.

برای مثال، جهت تنظیم تعداد نخ‌های GC هم‌روند روی 2، گزینهٔ زیر را مشخص کنید:

-XX:ConcGCThreads=2

-XX:+DisableExplicitGC

گزینه‌ای را فعال می‌کند که پردازش فراخوانی‌های System.gc() را غیرفعال می‌سازد. این گزینه به‌طور پیش‌فرض غیرفعال است، به این معنی که فراخوانی‌های System.gc() پردازش می‌شوند. اگر پردازش فراخوانی‌های System.gc() غیرفعال شود، JVM همچنان در صورت نیاز GC را انجام می‌دهد.

-XX:+ExplicitGCInvokesConcurrent

فراخوانی GC هم‌روند را با استفاده از درخواست System.gc() فعال می‌کند. این گزینه به‌طور پیش‌فرض غیرفعال است و تنها می‌تواند همراه با گزینهٔ -XX:+UseConcMarkSweepGC فعال شود.

-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses

فراخوانی GC هم‌روند را با استفاده از درخواست System.gc() و تخلیهٔ کلاس‌ها در طول چرخهٔ GC هم‌روند فعال می‌کند. این گزینه به‌طور پیش‌فرض غیرفعال است و تنها می‌تواند همراه با گزینهٔ -XX:+UseConcMarkSweepGC فعال شود.

-XX:G1HeapRegionSize=size

اندازهٔ ناحیه‌هایی را تنظیم می‌کند که هیپ جاوا هنگام استفاده از گردآورندهٔ garbage-first (G1) به آن‌ها تقسیم می‌شود. این مقدار می‌تواند بین 1 مگابایت و 32 مگابایت باشد. اندازهٔ پیش‌فرض ناحیه به‌صورت ارگونومیک بر اساس اندازهٔ هیپ تعیین می‌شود.

مثال زیر نحوهٔ تنظیم اندازهٔ بخش‌ها روی 16 مگابایت را نشان می‌دهد:

-XX:G1HeapRegionSize=16m

-XX:+G1PrintHeapRegions

چاپ اطلاعات مربوط به اینکه کدام ناحیه‌ها توسط گردآورندهٔ G1 تخصیص یافته و کدام‌یک بازپس‌گرفته شده‌اند را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است.

-XX:G1ReservePercent=percent

درصدی از هیپ را (0 تا 50) که به‌عنوان سقف کاذب برای کاهش احتمال شکست ارتقا (promotion failure) در گردآورندهٔ G1 رزرو می‌شود، تنظیم می‌کند. به‌طور پیش‌فرض، این گزینه روی 10% تنظیم شده است.

مثال زیر نحوهٔ تنظیم هیپ رزروشده روی 20% را نشان می‌دهد:

-XX:G1ReservePercent=20

-XX:InitialHeapSize=size

اندازهٔ اولیه (به بایت) استخر تخصیص حافظه را تنظیم می‌کند. این مقدار باید یا 0 باشد، یا مضربی از 1024 و بزرگ‌تر از 1 مگابایت. برای نشان دادن کیلوبایت، حرف k یا K، برای نشان دادن مگابایت، حرف m یا M، و برای نشان دادن گیگابایت، حرف g یا G را اضافه کنید. مقدار پیش‌فرض در زمان اجرا بر اساس پیکربندی سیستم انتخاب می‌شود. بخش «Ergonomics» را در Java SE HotSpot Virtual Machine Garbage Collection Tuning Guide در نشانی http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html ببینید. مثال‌های زیر نحوهٔ تنظیم اندازهٔ حافظهٔ تخصیص‌یافته روی ۶ مگابایت را با استفاده از واحدهای مختلف نشان می‌دهند: 
-XX:InitialHeapSize=6291456
-XX:InitialHeapSize=6144k
-XX:InitialHeapSize=6m
اگر این گزینه را روی 0 تنظیم کنید، اندازهٔ اولیه برابر با مجموع اندازه‌های تخصیص‌یافته برای نسل قدیم (old generation) و نسل جوان (young generation) تنظیم می‌شود. اندازهٔ هیپ برای نسل جوان را می‌توان با استفاده از گزینهٔ -XX:NewSize تنظیم کرد.

-XX:InitialSurvivorRatio=ratio

نسبت اولیهٔ فضای بازمانده (survivor space) مورد استفاده توسط زباله‌روب بازدهی (throughput garbage collector) را تنظیم می‌کند (که با گزینه‌های -XX:+UseParallelGC و/یا -XX:+UseParallelOldGC فعال می‌شود). تنظیم اندازهٔ تطبیقی به‌طور پیش‌فرض در زباله‌روب بازدهی با استفاده از گزینه‌های -XX:+UseParallelGC و -XX:+UseParallelOldGC فعال است، و فضای بازمانده متناسب با رفتار برنامه، با شروع از مقدار اولیه تغییر اندازه می‌یابد. اگر تنظیم اندازهٔ تطبیقی غیرفعال باشد (با استفاده از گزینهٔ -XX:-UseAdaptiveSizePolicy)، آنگاه باید از گزینهٔ -XX:SurvivorRatio برای تعیین اندازهٔ فضای بازمانده در تمام طول اجرای برنامه استفاده شود.

از فرمول زیر می‌توان برای محاسبهٔ اندازهٔ اولیهٔ فضای بازمانده (S) بر اساس اندازهٔ نسل جوان (Y) و نسبت اولیهٔ فضای بازمانده (R) استفاده کرد:

S=Y/(R+2)
عدد 2 در این معادله نشان‌دهندهٔ دو فضای بازمانده است. هرچه مقدار تعیین‌شده به عنوان نسبت اولیهٔ فضای بازمانده بزرگ‌تر باشد، اندازهٔ اولیهٔ فضای بازمانده کوچک‌تر خواهد بود.

به‌طور پیش‌فرض، نسبت اولیهٔ فضای بازمانده روی 8 تنظیم شده است. در صورت استفاده از مقدار پیش‌فرض اندازهٔ فضای نسل جوان (2 مگابایت)، اندازهٔ اولیهٔ فضای بازمانده 0.2 مگابایت خواهد بود.

مثال زیر نحوهٔ تنظیم نسبت اولیهٔ فضای بازمانده را روی 4 نشان می‌دهد:

-XX:InitialSurvivorRatio=4

-XX:InitiatingHeapOccupancyPercent=percent

درصد اشغال هیپ (0 تا 100) را برای شروع یک چرخهٔ هم‌روند GC تعیین می‌کند. این گزینه توسط زباله‌روب‌هایی استفاده می‌شود که چرخهٔ هم‌روند GC را بر اساس میزان اشغال کل هیپ آغاز می‌کنند، نه فقط یکی از نسل‌ها (برای مثال، زباله‌روب G1).

به‌طور پیش‌فرض، مقدار آغازین روی 45% تنظیم شده است. مقدار 0 به معنای چرخه‌های GC بی‌وقفه است. مثال زیر نحوهٔ تنظیم درصد اشغال آغازین هیپ را روی 75% نشان می‌دهد:

-XX:InitiatingHeapOccupancyPercent=75

-XX:MaxGCPauseMillis=time

یک هدف برای بیشینهٔ زمان توقف GC (به میلی‌ثانیه) تعیین می‌کند. این یک هدف انعطاف‌پذیر (soft goal) است و JVM تمام تلاش خود را برای رسیدن به آن انجام خواهد داد. به‌طور پیش‌فرض، هیچ مقداری برای بیشینهٔ زمان توقف تعیین نشده است.

مثال زیر نحوهٔ تنظیم هدف بیشینهٔ زمان توقف را روی 500 میلی‌ثانیه نشان می‌دهد:

-XX:MaxGCPauseMillis=500

-XX:MaxHeapSize=size

بیشینهٔ اندازهٔ (به بایت) استخر تخصیص حافظه را تعیین می‌کند. این مقدار باید مضربی از 1024 و بزرگ‌تر از 2 مگابایت باشد. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، و g یا G را برای گیگابایت اضافه کنید. مقدار پیش‌فرض در زمان اجرا بر اساس پیکربندی سیستم انتخاب می‌شود. در استقرارهای سرور، -XX:InitialHeapSize و -XX:MaxHeapSize اغلب روی مقداری یکسان تنظیم می‌شوند. بخش «Ergonomics» را در Java SE HotSpot Virtual Machine Garbage Collection Tuning Guide در http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html ببینید.

مثال‌های زیر نحوهٔ تنظیم بیشینهٔ اندازهٔ مجاز حافظهٔ تخصیص‌یافته روی 80 مگابایت را با استفاده از واحدهای مختلف نشان می‌دهند:

-XX:MaxHeapSize=83886080
-XX:MaxHeapSize=81920k
-XX:MaxHeapSize=80m
در بسترهای SPARC سیستم‌عامل‌های Oracle Solaris 7 و Oracle Solaris 8، حد بالای این مقدار تقریباً 4,000 مگابایت منهای مقادیر سربار است. در Oracle Solaris 2.6 و بسترهای x86، حد بالا تقریباً 2,000 مگابایت منهای مقادیر سربار است. در بسترهای لینوکس، حد بالا تقریباً 2,000 مگابایت منهای مقادیر سربار است.

گزینهٔ -XX:MaxHeapSize معادل -Xmx است.

-XX:MaxHeapFreeRatio=percent

بیشینهٔ درصد مجاز فضای آزاد هیپ (0 تا 100) پس از یک رویداد GC را تعیین می‌کند. اگر فضای آزاد هیپ فراتر از این مقدار گسترش یابد، هیپ کوچک خواهد شد. به‌طور پیش‌فرض، این مقدار روی 70% تنظیم شده است.

مثال زیر نحوهٔ تنظیم بیشینهٔ نسبت فضای آزاد هیپ را روی 75% نشان می‌دهد:

-XX:MaxHeapFreeRatio=75

-XX:MaxMetaspaceSize=size

بیشینهٔ مقدار حافظهٔ محلی (native memory) قابل تخصیص برای فراداده‌های کلاس (class metadata) را تعیین می‌کند. به‌طور پیش‌فرض، این اندازه نامحدود است. مقدار فراداده برای یک برنامه به خود برنامه، سایر برنامه‌های در حال اجرا و مقدار حافظهٔ در دسترس سیستم بستگی دارد.

مثال زیر نحوهٔ تنظیم بیشینهٔ اندازهٔ فراداده‌های کلاس روی 256 مگابایت را نشان می‌دهد:

-XX:MaxMetaspaceSize=256m
-XX:MaxNewSize=size
حداکثر اندازه (به بایت) هیپ را برای نسل جوان (nursery) تعیین می‌کند. مقدار پیش‌فرض به‌صورت خودکار و ارگونومیک تنظیم می‌شود.

-XX:MaxTenuringThreshold=threshold

حداکثر آستانه ارتقا (tenuring threshold) را برای استفاده در تعیین اندازه تطبیقی GC مشخص می‌کند. بزرگ‌ترین مقدار ممکن ۱۵ است. مقدار پیش‌فرض برای گردآورنده موازی (parallel/throughput collector) برابر با ۱۵، و برای گردآورنده CMS برابر با ۶ است.

مثال زیر نحوه تنظیم حداکثر آستانه ارتقا روی ۱۰ را نشان می‌دهد:

-XX:MaxTenuringThreshold=10

-XX:MetaspaceSize=size

اندازه فضای تخصیص‌یافته برای متاداده‌های کلاس (class metadata) را مشخص می‌کند که با فراتر رفتن از آن برای اولین بار، یک زباله‌روبی (GC) آغاز خواهد شد. این آستانه برای زباله‌روبی بسته به میزان متاداده‌های مصرف‌شده افزایش یا کاهش می‌یابد. اندازه پیش‌فرض به بستر (platform) بستگی دارد.

-XX:MinHeapFreeRatio=percent

حداقل درصد مجاز فضای خالی هیپ (۰ تا ۱۰۰) پس از یک رویداد GC را تعیین می‌کند. اگر فضای خالی هیپ به زیر این مقدار کاهش یابد، هیپ گسترش خواهد یافت. به‌طور پیش‌فرض، این مقدار روی ۴۰٪ تنظیم شده است.

مثال زیر نحوه تنظیم حداقل نسبت فضای خالی هیپ به ۲۵٪ را نشان می‌دهد:

-XX:MinHeapFreeRatio=25

-XX:NewRatio=ratio

نسبت میان اندازه نسل جوان (young generation) و نسل کهن (old generation) را تعیین می‌کند. به‌طور پیش‌فرض، این گزینه روی ۲ تنظیم شده است. مثال زیر نحوه تنظیم نسبت نسل جوان به کهن را به ۱ نشان می‌دهد: 
-XX:NewRatio=1

-XX:NewSize=size

اندازه اولیه (به بایت) هیپ را برای نسل جوان (nursery) تعیین می‌کند. نویسه k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، و g یا G را برای گیگابایت به انتهای مقدار اضافه کنید.

ناحیه نسل جوان در هیپ برای اشیاء جدید استفاده می‌شود. فرآیند GC در این ناحیه با بسامد بیشتری نسبت به سایر نواحی اجرا می‌شود. اگر اندازه نسل جوان بیش از حد کم باشد، تعداد زیادی GC کوچک (minor GC) انجام خواهد شد. اگر اندازه بیش از حد بزرگ باشد، تنها GCهای کامل (full GC) اجرا می‌شوند که تکمیل آن‌ها ممکن است زمان زیادی طول بکشد. شرکت Oracle توصیه می‌کند که اندازه نسل جوان را بین یک‌دوم تا یک‌چهارم اندازه کلی هیپ نگه دارید.

مثال‌های زیر نحوه تعیین اندازه اولیه نسل جوان به ۲۵۶ مگابایت را با واحدهای مختلف نشان می‌دهند:

-XX:NewSize=256m
-XX:NewSize=262144k
-XX:NewSize=268435456
گزینه -XX:NewSize معادل -Xmn است.

-XX:ParallelGCThreads=threads

تعداد ریسه‌های (threads) مورد استفاده برای زباله‌روبی موازی در نسل‌های جوان و کهن را تعیین می‌کند. مقدار پیش‌فرض به تعداد پردازنده‌های موجود برای JVM بستگی دارد.

برای مثال، جهت تنظیم تعداد ریسه‌های GC موازی به ۲، گزینه زیر را مشخص کنید:

-XX:ParallelGCThreads=2

-XX:+ParallelRefProcEnabled

پردازش موازی ارجاعات را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است.

-XX:+PrintAdaptiveSizePolicy

چاپ اطلاعات مربوط به اندازه‌بندی تطبیقی نسل‌ها را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است.

-XX:+PrintGC

چاپ پیام‌ها در هنگام هر GC را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است.

-XX:+PrintGCApplicationConcurrentTime

چاپ میزان زمان سپری‌شده پس از آخرین توقف (برای مثال، توقف GC) را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است.

-XX:+PrintGCApplicationStoppedTime

چاپ مدت‌زمان طول کشیدن توقف (برای مثال، توقف GC) را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است.

-XX:+PrintGCDateStamps

چاپ برچسب تاریخ در هنگام هر GC را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است.

-XX:+PrintGCDetails

چاپ پیام‌های تفصیلی در هنگام هر GC را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است.

-XX:+PrintGCTaskTimeStamps

چاپ برچسب‌های زمانی برای هر وظیفه از ریسه‌های کارگر GC را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است.

-XX:+PrintGCTimeStamps

چاپ برچسب‌های زمانی در هنگام هر GC را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است.

-XX:+PrintStringDeduplicationStatistics

آمار تفصیلی حذف رشته‌های تکراری (deduplication) را چاپ می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است. به گزینه -XX:+UseStringDeduplication مراجعه کنید.

-XX:+PrintTenuringDistribution

چاپ اطلاعات سن ارتقا (tenuring age) را فعال می‌کند. در ادامه مثالی از خروجی آورده شده است: 
Desired survivor size 48286924 bytes, new threshold 10 (max 10)
- age 1: 28992024 bytes, 28992024 total
- age 2: 1366864 bytes, 30358888 total
- age 3: 1425912 bytes, 31784800 total
...
اشیاء با سن ۱ (Age 1) جوان‌ترین بازماندگان هستند (آن‌ها پس از پاک‌سازی پیشین ایجاد شده‌اند، در آخرین پاک‌سازی جان سالم به در برده‌اند و از فضای eden به فضای survivor منتقل شده‌اند). اشیاء با سن ۲ از دو دوره پاک‌سازی نجات یافته‌اند (طی دومین پاک‌سازی، از یک فضای survivor به فضای بعدی کپی شده‌اند). و به همین ترتیب ادامه می‌یابد. در مثال پیشین، 28 992 024 بایت از یک scavenge جان سالم به در برده و از eden به فضای survivor کپی شدند، 1 366 864 بایت توسط اشیاء با سن 2 اشغال شده است، و غیره. مقدار سوم در هر سطر، اندازهٔ تجمعی اشیاء با سن n یا کمتر است.

به‌طور پیش‌فرض، این گزینه غیرفعال است.

-XX:+ScavengeBeforeFullGC

اجرای GC روی نسل جوان را پیش از هر full GC فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. شرکت Oracle توصیه می‌کند که آن را غیرفعال نکنید، زیرا پاکسازی نسل جوان پیش از یک full GC می‌تواند تعداد اشیاء قابل دسترسی از فضای نسل قدیم به فضای نسل جوان را کاهش دهد. برای غیرفعال کردن GC روی نسل جوان پیش از هر full GC، گزینهٔ -XX:-ScavengeBeforeFullGC را مشخص کنید.

-XX:SoftRefLRUPolicyMSPerMB=time

مدت زمانی (به میلی‌ثانیه) را تعیین می‌کند که یک شیء با ارجاع نرم (softly reachable) پس از آخرین باری که به آن ارجاع داده شده است، در heap فعال نگه‌داشته می‌شود. مقدار پیش‌فرض، یک ثانیه طول عمر به ازای هر مگابایت آزاد در heap است. گزینهٔ -XX:SoftRefLRUPolicyMSPerMB مقادیر صحیحی را می‌پذیرد که نشان‌دهندهٔ میلی‌ثانیه به ازای هر یک مگابایت از اندازهٔ فعلی heap (برای Java HotSpot Client VM) یا حداکثر اندازهٔ ممکن heap (برای Java HotSpot Server VM) هستند. این تفاوت به این معنی است که Client VM ترجیح می‌دهد ارجاع‌های نرم را پاکسازی کند تا اینکه اندازهٔ heap را افزایش دهد، در حالی که Server VM ترجیح می‌دهد اندازهٔ heap را افزایش دهد تا اینکه ارجاع‌های نرم را پاکسازی کند. در مورد اخیر، مقدار گزینهٔ -Xmx تأثیر بسزایی بر سرعت جمع‌آوری زبالهٔ ارجاع‌های نرم دارد.

مثال زیر نحوهٔ تنظیم این مقدار را روی 2.5 ثانیه نشان می‌دهد:

-XX:SoftRefLRUPolicyMSPerMB=2500

-XX:StringDeduplicationAgeThreshold=threshold

اشیاء String که به سن مشخص‌شده می‌رسند، به عنوان نامزدهایی برای deduplication (حذف داده‌های تکراری) در نظر گرفته می‌شوند. سن یک شیء معیاری از دفعاتی است که از فرایند جمع‌آوری زباله جان سالم به در برده است. این موضوع گاهی ارتقا به دورهٔ ماندگاری (tenuring) نامیده می‌شود؛ گزینهٔ -XX:+PrintTenuringDistribution را ببینید. توجه داشته باشید اشیاء String که پیش از رسیدن به این سن به یک ناحیهٔ قدیمی در heap ارتقا می‌یابند، همواره کاندید deduplication محسوب می‌شوند. مقدار پیش‌فرض برای این گزینه 3 است. گزینهٔ -XX:+UseStringDeduplication را ببینید.

-XX:SurvivorRatio=ratio

نسبت میان اندازهٔ فضای eden و اندازهٔ فضای survivor را تنظیم می‌کند. به‌طور پیش‌فرض، این گزینه روی 8 تنظیم شده است. مثال زیر نحوهٔ تنظیم نسبت فضای eden/survivor روی 4 را نشان می‌دهد: 
-XX:SurvivorRatio=4

-XX:TargetSurvivorRatio=percent

درصد مورد نظر از فضای survivor (از 0 تا 100) را که پس از young garbage collection استفاده می‌شود، تنظیم می‌کند. به‌طور پیش‌فرض، این گزینه روی 50% تنظیم شده است.

مثال زیر نحوهٔ تنظیم نسبت هدف فضای survivor به 30% را نشان می‌دهد:

-XX:TargetSurvivorRatio=30

-XX:TLABSize=size

اندازهٔ اولیه (به بایت) یک بافر تخصیص محلی رشته (TLAB) را تعیین می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، و g یا G را برای گیگابایت ضمیمه کنید. اگر این گزینه روی 0 تنظیم شود، JVM اندازهٔ اولیه را به‌طور خودکار انتخاب می‌کند.

مثال زیر نحوهٔ تنظیم اندازهٔ اولیهٔ TLAB به 512 کیلوبایت را نشان می‌دهد:

-XX:TLABSize=512k

-XX:+UseAdaptiveSizePolicy

استفاده از تعیین اندازهٔ تطبیقی نسل‌ها را فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن اندازه‌بندی تطبیقی نسل‌ها، -XX:-UseAdaptiveSizePolicy را مشخص کرده و اندازهٔ استخر تخصیص حافظه را به‌طور صریح تنظیم کنید (گزینهٔ -XX:SurvivorRatio را ببینید).

-XX:+UseCMSInitiatingOccupancyOnly

استفاده از مقدار اشغال حافظه را به عنوان تنها معیار برای شروع جمع‌آور CMS فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و ممکن است از معیارهای دیگری استفاده شود.

-XX:+UseConcMarkSweepGC

استفاده از جمع‌آور زبالهٔ CMS را برای نسل قدیم فعال می‌کند. Oracle توصیه می‌کند زمانی که الزامات تأخیر برنامه توسط جمع‌آور زبالهٔ توان‌محور (-XX:+UseParallelGC) برآورده نمی‌شود، از جمع‌آور زبالهٔ CMS استفاده کنید. جمع‌آور زبالهٔ G1 (-XX:+UseG1GC) گزینهٔ جایگزین دیگری است.

به‌طور پیش‌فرض، این گزینه غیرفعال است و جمع‌آور بر اساس پیکربندی ماشین و نوع JVM به‌طور خودکار انتخاب می‌شود. با فعال شدن این گزینه، گزینهٔ -XX:+UseParNewGC به‌طور خودکار تنظیم می‌شود و نباید آن را غیرفعال کنید، زیرا ترکیب گزینه‌های زیر در JDK 8 منسوخ شده است: -XX:+UseConcMarkSweepGC -XX:-UseParNewGC.

-XX:+UseG1GC

استفاده از جمع‌آور زبالهٔ garbage-first (G1) را فعال می‌کند. این یک جمع‌آور زبالهٔ مناسب سرور است که برای ماشین‌های چندپردازنده‌ای با حجم زیادی حافظهٔ RAM هدف‌گذاری شده است. این جمع‌آور با احتمال بالایی به اهداف زمان مکث GC دست می‌یابد، در حالی که توان عملیاتی مناسبی را حفظ می‌کند. جمع‌آور G1 برای برنامه‌هایی توصیه می‌شود که نیازمند heap بزرگ (اندازه‌های حدود 6 گیگابایت یا بزرگ‌تر) همراه با الزامات تأخیر محدود GC (زمان مکث پایدار و قابل پیش‌بینی زیر 0.5 ثانیه) هستند.

به‌طور پیش‌فرض، این گزینه غیرفعال است و جمع‌آور بر اساس پیکربندی ماشین و نوع JVM به‌طور خودکار انتخاب می‌شود.

-XX:+UseGCOverheadLimit

استفاده از سیاستی را فعال می‌کند که نسبت زمان صرف‌شده توسط JVM برای GC را پیش از پرتاب استثنای OutOfMemoryError محدود می‌کند. این گزینه به‌طور پیش‌فرض فعال است و اگر بیش از 98% از کل زمان صرف جمع‌آوری زباله شود و کمتر از 2% از heap بازیابی گردد، GC موازی یک OutOfMemoryError پرتاب خواهد کرد. هنگامی که heap کوچک است، این ویژگی می‌تواند برای جلوگیری از اجرای طولانی‌مدت برنامه‌ها بدون پیشرفت یا با پیشرفت ناچیز به کار رود. برای غیرفعال کردن این گزینه، -XX:-UseGCOverheadLimit را مشخص کنید.

-XX:+UseNUMA

بهینه‌سازی کارایی برنامه را روی ماشینی با معماری حافظه غیریکنواخت (NUMA) از طریق افزایش استفادهٔ برنامه از حافظه با تأخیر کمتر فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و هیچ بهینه‌سازی برای NUMA انجام نمی‌شود. این گزینه تنها زمانی در دسترس است که از جمع‌آور زبالهٔ موازی (-XX:+UseParallelGC) استفاده شود.

-XX:+UseParallelGC

استفاده از جمع‌آور زبالهٔ parallel scavenge (که با نام جمع‌آور توان عملیاتی یا throughput نیز شناخته می‌شود) را فعال می‌کند تا با بهره‌گیری از چندین پردازنده، کارایی برنامهٔ شما را بهبود بخشد.

به‌طور پیش‌فرض، این گزینه غیرفعال است و جمع‌آور بر اساس پیکربندی ماشین و نوع JVM به‌طور خودکار انتخاب می‌شود. اگر این گزینه فعال باشد، گزینهٔ -XX:+UseParallelOldGC نیز به‌طور خودکار فعال می‌شود، مگر اینکه آن را به صراحت غیرفعال کنید.

-XX:+UseParallelOldGC

استفاده از جمع‌آور زبالهٔ موازی را برای full GCها فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است. فعال کردن آن به‌طور خودکار گزینهٔ -XX:+UseParallelGC را فعال می‌کند.

-XX:+UseParNewGC

استفاده از رشته‌های موازی را برای جمع‌آوری در نسل جوان فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است. هنگامی که گزینهٔ -XX:+UseConcMarkSweepGC را تنظیم می‌کنید، به‌طور خودکار فعال می‌شود. استفاده از گزینهٔ -XX:+UseParNewGC بدون گزینهٔ -XX:+UseConcMarkSweepGC در JDK 8 منسوخ شده است. -XX:+UseSerialGC
استفاده از زباله‌روب ترتیبی (serial garbage collector) را فعال می‌کند. این گزینه عموماً بهترین انتخاب برای برنامه‌های کوچک و ساده‌ای است که به هیچ قابلیت ویژه‌ای از فرایند زباله‌روبی نیاز ندارند. به‌طور پیش‌فرض، این گزینه غیرفعال است و زباله‌روب به‌طور خودکار بر اساس پیکربندی ماشین و نوع JVM انتخاب می‌شود.

-XX:+UseSHM

در لینوکس، به JVM امکان می‌دهد تا از حافظه اشتراکی (shared memory) برای راه‌اندازی صفحه‌های بزرگ (large pages) استفاده کند.

برای اطلاعات بیشتر، بخش «Large Pages» را ببینید.

-XX:+UseStringDeduplication

یکتاسازی رشته‌ها (string deduplication) را فعال می‌کند. این گزینه به‌طور پیش‌فرض غیرفعال است. برای استفاده از این گزینه، باید زباله‌روب G1 (garbage-first) را فعال کنید. گزینه -XX:+UseG1GC را ببینید.

یکتاسازی رشته‌ها با بهره‌گیری از این واقعیت که بسیاری از اشیاء String یکسان هستند، ردپای حافظه اشیاء String را روی Java heap کاهش می‌دهد. به جای اینکه هر شیء String به آرایه نویسه‌ای مخصوص به خود اشاره کند، اشیاء یکسان String می‌توانند به یک آرایه نویسه‌ای مشترک اشاره کنند و آن را به اشتراک بگذارند.

-XX:+UseTLAB

استفاده از بلوک‌های تخصیص محلی نخ (TLABها) را در فضای نسل جوان (young generation) فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن استفاده از TLABها، گزینه -XX:-UseTLAB را مشخص کنید.

این گزینه‌ها در انتشار پیشین گنجانده شده بودند، اما از آن زمان به بعد غیرضروری تشخیص داده شده‌اند.

-Xincgc

زباله‌روبی افزایشی (incremental garbage collection) را فعال می‌کند. این گزینه در JDK 8 بدون هیچ جایگزینی منسوخ شد.

-Xrunlibname

کتابخانه اشکال‌زدایی/تحلیل کارایی (debugging/profiling) مشخص‌شده را بارگذاری می‌کند. این گزینه با گزینه -agentlib جایگزین شده است.

-XX:CMSIncrementalDutyCycle=percent

درصد زمانی (۰ تا ۱۰۰) بین زباله‌روبی‌های جزئی که زباله‌روب همگام اجازه اجرا دارد را تنظیم می‌کند. این گزینه در JDK 8 به دنبال منسوخ شدن گزینه -XX:+CMSIncrementalMode بدون جایگزین منسوخ شد.

-XX:CMSIncrementalDutyCycleMin=percent

درصد زمانی (۰ تا ۱۰۰) بین زباله‌روبی‌های جزئی را تنظیم می‌کند که در صورت فعال بودن -XX:+CMSIncrementalPacing به عنوان کران پایین چرخه کارکرد (duty cycle) در نظر گرفته می‌شود. این گزینه در JDK 8 به دنبال منسوخ شدن گزینه -XX:+CMSIncrementalMode بدون جایگزین منسوخ شد.

-XX:+CMSIncrementalMode

حالت افزایشی را برای زباله‌روب CMS فعال می‌کند. این گزینه در JDK 8 همراه با سایر گزینه‌هایی که با CMSIncremental آغاز می‌شوند، بدون جایگزین منسوخ شد.

-XX:CMSIncrementalOffset=percent

درصد زمانی (۰ تا ۱۰۰) را تعیین می‌کند که چرخه کارکرد حالت افزایشی به همان میزان در بازه بین زباله‌روبی‌های جزئی به سمت راست منتقل (شیفت) می‌شود. این گزینه در JDK 8 به دنبال منسوخ شدن گزینه -XX:+CMSIncrementalMode بدون جایگزین منسوخ شد.

-XX:+CMSIncrementalPacing

تنظیم خودکار چرخه کارکرد حالت افزایشی را بر اساس آمارهای جمع‌آوری‌شده در حین اجرای JVM فعال می‌کند. این گزینه در JDK 8 به دنبال منسوخ شدن گزینه -XX:+CMSIncrementalMode بدون جایگزین منسوخ شد.

-XX:CMSIncrementalSafetyFactor=percent

درصد زمانی (۰ تا ۱۰۰) را تعیین می‌کند که جهت رعایت احتیاط در هنگام محاسبه چرخه کارکرد لحاظ می‌شود. این گزینه در JDK 8 به دنبال منسوخ شدن گزینه -XX:+CMSIncrementalMode بدون جایگزین منسوخ شد.

-XX:CMSInitiatingPermOccupancyFraction=percent

درصد اشغال فضای نسل ماندگار (permanent generation) از ۰ تا ۱۰۰ را که در آن یک دوره GC آغاز می‌شود تعیین می‌کند. این گزینه در JDK 8 بدون جایگزین منسوخ شد.

-XX:MaxPermSize=size

حداکثر اندازه فضای نسل ماندگار (permanent generation) را (بر حسب بایت) تعیین می‌کند. این گزینه در JDK 8 منسوخ شده و با گزینه -XX:MaxMetaspaceSize جایگزین گردید.

-XX:PermSize=size

میزان فضای تخصیص‌یافته به نسل ماندگار (permanent generation) را (بر حسب بایت) تعیین می‌کند که در صورت فراتر رفتن از آن، فرایند زباله‌روبی آغاز می‌شود. این گزینه در JDK 8 منسوخ شده و با گزینه -XX:MetaspaceSize جایگزین گردید.

-XX:+UseSplitVerifier

تفکیک فرایند راستی‌آزمایی (verification) را فعال می‌کند. این گزینه در انتشار‌های قبلی به‌طور پیش‌فرض فعال بود و راستی‌آزمایی به دو مرحله تفکیک می‌شد: ارجاع نوع (توسط کامپایلر) و بررسی نوع (توسط محیط زمان اجرای JVM). این گزینه در JDK 8 منسوخ شده است و راستی‌آزمایی اکنون به‌طور پیش‌فرض تفکیک می‌شود و راهی برای غیرفعال کردن آن وجود ندارد.

-XX:+UseStringCache

ذخیره‌سازی موقت (caching) رشته‌های مکرراً تخصیص‌یافته را فعال می‌کند. این گزینه از JDK 8 بدون هیچ جایگزینی حذف شد.

مثال‌های زیر نحوه استفاده از پرچم‌های آزمایشی تنظیم عملکرد را برای بهینه‌سازی توان عملیاتی یا دستیابی به زمان پاسخ‌دهی کمتر نشان می‌دهند.

مثال ۱ تنظیم برای توان عملیاتی بالاتر

java -d64 -server -XX:+AggressiveOpts -XX:+UseLargePages -Xmn10g  -Xms26g -Xmx26g

مثال ۲ تنظیم برای زمان پاسخ‌دهی کمتر

java -d64 -XX:+UseG1GC -Xms26g Xmx26g -XX:MaxGCPauseMillis=500 -XX:+PrintGCTimeStamp

صفحات بزرگ (Large pages) که با عنوان huge pages نیز شناخته می‌شوند، صفحاتی از حافظه هستند که به طور قابل توجهی از اندازه استاندارد صفحه حافظه (که بسته به پردازنده و سیستم‌عامل متفاوت است) بزرگ‌ترند. صفحات بزرگ بافرهای ترجمه آدرس پردازنده (Translation-Lookaside Buffers) را بهینه‌سازی می‌کنند.

یک بافر ترجمه آدرس (Translation-Lookaside Buffer یا TLB) یک حافظه نهان (کش) برای ترجمه صفحه است که آخرین ترجمه‌های استفاده‌شده از نشانی مجازی به فیزیکی را نگه‌داری می‌کند. حافظه TLB یک منبع سیستمی کمیاب است. خطای نبود در TLB (یا TLB miss) می‌تواند هزینه‌بر باشد، زیرا پردازنده باید از جدول سلسله‌مراتبی صفحات بخواند که ممکن است به چندین بار دسترسی به حافظه نیاز داشته باشد. با استفاده از اندازه صفحه حافظه بزرگ‌تر، هر مدخل منفرد در TLB می‌تواند محدوده حافظه بزرگ‌تری را پوشش دهد. در نتیجه، فشار کمتری بر TLB وارد خواهد شد و برنامه‌های کاربردی با مصرف حافظه سنگین ممکن است کارایی بهتری داشته باشند.

با این حال، حافظه با صفحات بزرگ می‌تواند اثر منفی بر عملکرد سیستم بگذارد. به عنوان مثال، هنگامی که مقدار زیادی از حافظه توسط یک برنامه پین (pin) یا تثبیت می‌شود، ممکن است کمبود حافظه معمولی ایجاد کند و باعث صفحه‌بندی (paging) بیش از حد در سایر برنامه‌ها شده و کل سیستم را کند سازد. همچنین، سیستمی که برای مدتی طولانی فعال بوده است ممکن است دچار تکه‌تکه‌شدن (fragmentation) بیش از حد حافظه شود که امکان رزرو حافظه کافی برای صفحات بزرگ را ناممکن می‌سازد. در چنین شرایطی، سیستم‌عامل یا JVM به استفاده از صفحات معمولی برمی‌گردند.

سیستم‌عامل‌های Solaris و Linux از صفحات بزرگ پشتیبانی می‌کنند.

Solaris

سیستم‌عامل Solaris 9 و نسخه‌های جدیدتر شامل قابلیت Multiple Page Size Support (MPSS) هستند؛ هیچ پیکربندی اضافی لازم نیست. ببینید: http://www.oracle.com/technetwork/server-storage/solaris10/overview/solaris9-features-scalability-135663.html.

Linux

هسته 2.6 از صفحات بزرگ پشتیبانی می‌کند. برخی توزیع‌کنندگان این کد را به انتشارهای مبتنی بر 2.4 خود بک‌پورت (backport) کرده‌اند. برای بررسی اینکه آیا سیستم شما می‌تواند از حافظه با صفحات بزرگ پشتیبانی کند یا خیر، دستور زیر را امتحان کنید:

# cat /proc/meminfo | grep Huge
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 2048 kB

اگر خروجی، سه متغیر «Huge» را نشان دهد، سیستم شما می‌تواند از حافظه صفحات بزرگ پشتیبانی کند اما نیاز به پیکربندی دارد. اگر این دستور چیزی چاپ نکرد، سیستم شما از صفحات بزرگ پشتیبانی نمی‌کند. برای پیکربندی سیستم جهت استفاده از حافظه صفحات بزرگ، به عنوان کاربر root وارد شوید و سپس این مراحل را دنبال کنید:

1.اگر از گزینه -XX:+UseSHM (به جای -XX:+UseHugeTLBFS) استفاده می‌کنید، مقدار SHMMAX را افزایش دهید. این مقدار باید بزرگ‌تر از اندازه Java heap باشد. روی سیستمی با ۴ گیگابایت حافظه فیزیکی RAM (یا کمتر)، دستور زیر تمام حافظه را قابل اشتراک‌گذاری می‌کند: 
# echo 4294967295 > /proc/sys/kernel/shmmax
2.اگر از گزینه -XX:+UseSHM یا -XX:+UseHugeTLBFS استفاده می‌کنید، تعداد صفحات بزرگ را مشخص کنید. در مثال زیر، ۳ گیگابایت از یک سیستم ۴ گیگابایتی برای صفحات بزرگ رزرو شده است (با فرض اندازه صفحه بزرگ برابر ۲۰۴۸ کیلوبایت، در این صورت 3 GB = 3 * 1024 MB = 3072 MB = 3072 * 1024 kB = 3145728 kB و 3145728 kB / 2048 kB = 1536 خواهد بود): 
# echo 1536 > /proc/sys/vm/nr_hugepages

نکته
4 • توجه داشته باشید که مقادیر موجود در /proc پس از راه‌اندازی مجدد (reboot) سیستم بازنشانی می‌شوند، بنابراین ممکن است بخواهید آن‌ها را در یک اسکریپت راه‌اندازی (برای مثال rc.local یا sysctl.conf) تنظیم کنید. 4 • اگر پارامترهای هسته سیستم‌عامل /proc/sys/kernel/shmmax یا /proc/sys/vm/nr_hugepages را پیکربندی کنید (یا اندازه آن‌ها را تغییر دهید)، پردازه‌های Java ممکن است علاوه بر Java heap، برای بخش‌های دیگر نیز صفحات بزرگ تخصیص دهند. این مراحل می‌توانند برای بخش‌های زیر صفحات بزرگ تخصیص دهند: 4 • Java heap 4 • Code cache 4 • ساختار داده بیت‌مپ نشانه‌گذاری (marking bitmap) برای parallel GC در نتیجه، اگر پارامتر nr_hugepages را به اندازه Java heap تنظیم کنید، ممکن است JVM در تخصیص نواحی code cache بر روی صفحات بزرگ با خطا مواجه شود، زیرا اندازه این نواحی بسیار بزرگ است.
1
"وضعیت خروج (EXIT STATUS)"
مقادیر خروج زیر معمولاً هنگامی توسط اجراکننده بازگردانده می‌شوند که اجراکننده با آرگومان‌های نادرست فراخوانی شود، خطاهای جدی رخ دهند، یا استثناهایی توسط JVM پرتاب شوند. با این حال، یک برنامه Java می‌تواند با استفاده از فراخوانی APIِ
System.exit(exitValue) هر مقداری را بازگرداند. این مقادیر عبارتند از
4
•
0
4
•
>0
"همچنین ببینید (SEE ALSO)"
4
•
javac(1)
4
•
jdb(1)
4
•
jar(1)
4
•
jstat(1)
03 March 2015 JDK 8