JAVA(1) JDK Commands JAVA(1)

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

برای اجرای یک فایل کلاس:

java [options] mainclass [args ...]

برای اجرای کلاس اصلی در یک فایل JAR:

java [options] -jar jarfile [args ...]

برای اجرای کلاس اصلی در یک ماژول:

java [options] -m module[/mainclass] [args ...]

یا

java [options] --module module[/mainclass] [args ...]

برای اجرای یک برنامه از فایل منبع:

java [options] source-file [args ...]

اختیاری: گزینه‌های خط فرمان را مشخص می‌کند که با فاصله (space) از هم جدا می‌شوند. برای شرح گزینه‌های موجود، به Overview of Java Options مراجعه کنید.
نام کلاسی را که باید اجرا شود مشخص می‌کند. ورودی‌های خط فرمان پس از classname، آرگومان‌های متد اصلی (main) هستند.
برنامه‌ای را که در یک فایل JAR بسته‌بندی شده است اجرا می‌کند. آرگومان jarfile نام یک فایل JAR است که شامل مانیفستی با سطری به شکل Main-Class:classname می‌باشد؛ این سطر کلاسی را که دارای متد public static void main(String[] args) بوده و به عنوان نقطه آغازین برنامه شما عمل می‌کند تعریف می‌نماید. هنگامی که از -jar استفاده می‌کنید، فایل JAR مشخص‌شده منبع تمامی کلاس‌های کاربر است و سایر تنظیمات مسیر کلاس (class path) نادیده گرفته می‌شوند. اگر از فایل‌های JAR استفاده می‌کنید، به jar مراجعه کنید.
کلاس اصلی را در ماژول مشخص‌شده توسط mainclass (در صورت تعیین)، یا در صورت عدم تعیین، مقدار موجود در module اجرا می‌کند. به عبارت دیگر، mainclass می‌تواند زمانی استفاده شود که توسط ماژول مشخص نشده باشد، یا برای بازنویسی مقدار تعیین‌شده به کار رود.
به Standard Options for Java مراجعه کنید.
تنها برای اجرای برنامه‌های مبتنی بر فایل منبع استفاده می‌شود. فایل منبعی را که در زمان استفاده از حالت source-file حاوی کلاس اصلی است، مشخص می‌کند. به Using Source-File Mode to Launch Source-Code Programs مراجعه کنید.
اختیاری: آرگومان‌های پس از mainclass، source-file، -jar jarfile، و -m یا --module module/mainclass به عنوان آرگومان به کلاس اصلی ارسال می‌شوند.

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

public static void main(String[] args)

در حالت فایل منبع (source-file mode)، دستور java می‌تواند کلاسی را که درون یک فایل منبع اعلان شده است اجرا کند. برای توضیحات مربوط به استفاده از حالت فایل منبع، به Using Source-File Mode to Launch Source-Code Programs مراجعه کنید.

نکته: می‌توانید از متغیر محیطی اجراکننده JDK_JAVA_OPTIONS برای الصاق محتوای آن به ابتدای خط فرمان واقعی اجراکننده java استفاده کنید. به Using the JDK_JAVA_OPTIONS Launcher Environment Variable مراجعه کنید.

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

آرگومان‌های پس از نام فایل کلاس یا نام فایل JAR به متد main() ارسال می‌شوند..SS javaw ویندوز: دستور javaw کاملاً مشابه java است، با این تفاوت که با javaw هیچ پنجرهٔ کنسول مرتبطی باز نمی‌شود. زمانی از javaw استفاده کنید که نمی‌خواهید پنجرهٔ خط فرمان ظاهر شود. با این حال، در صورت شکست در راه‌اندازی، اجراکنندهٔ javaw کادر محاوره‌ای حاوی اطلاعات خطا نمایش خواهد داد.

برای راه‌اندازی کلاسی که در یک فایل منبع تعریف شده است، اجراکنندهٔ java را در حالت فایل منبع (source-file mode) اجرا کنید. ورود به حالت فایل منبع توسط دو مورد در خط فرمان java تعیین می‌شود:

  • نخستین مورد در خط فرمان که گزینه یا بخشی از یک گزینه نیست. به عبارت دیگر، موردی در خط فرمان که در غیر این صورت نام کلاس اصلی (main class) می‌بود.
  • گزینهٔ --source version، در صورت وجود.

اگر کلاس به یک فایل موجود اشاره کند که دارای پسوند .java است، یا اگر گزینهٔ --source مشخص شده باشد، حالت فایل منبع انتخاب می‌شود. سپس فایل منبع کامپایل و اجرا می‌گردد. گزینهٔ --source می‌تواند برای تعیین نسخهٔ منبع (version) یا N کد منبع استفاده شود. این مقدار، API قابل استفاده را تعیین می‌کند. هنگامی که --source N را مشخص می‌کنید، تنها می‌توانید از API عمومی‌ای که در JDK N تعریف شده است استفاده نمایید.

نکته: مقادیر معتبر N برای هر نسخه تغییر می‌کند و مقادیر جدید اضافه و مقادیر قدیمی حذف می‌شوند. اگر از مقداری برای N استفاده کنید که دیگر پشتیبانی نمی‌شود، پیام خطا دریافت خواهید کرد. مقادیر پشتیبانی‌شده برای N عبارتند از انتشار کنونی Java SE (26) و تعداد محدودی از نسخه‌های پیشین، که جزئیات آن‌ها در راهنمای خط فرمان javac، ذیل گزینه‌های --source و --release آمده است.

اگر فایل دارای پسوند .java نباشد، باید از گزینهٔ --source استفاده شود تا به دستور java اعلام کند از حالت فایل منبع استفاده کند. گزینهٔ --source برای مواردی به کار می‌رود که فایل منبع یک "اسکریپت" برای اجراست و نام فایل منبع از قواعد نام‌گذاری معمول فایل‌های منبع Java پیروی نمی‌کند.

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

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

java HelloWorld.java

این شیوهٔ استفاده از حالت فایل منبع به طور غیررسمی معادل استفاده از دو دستور زیر است:

javac -d <memory> --source-path <source-root> HelloWorld.java
java --class-path <memory> HelloWorld

که در آن <source-root> محاسبه می‌شود

در حالت فایل منبع، هرگونه گزینهٔ اضافی خط فرمان به صورت زیر پردازش می‌شود:

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

این موارد شامل این گزینه‌ها و شکل‌های مختلف آن‌هاست: --class-path، --module-path، --add-exports، --add-modules، --limit-modules، --patch-module، --upgrade-module-path. همچنین شامل گزینهٔ جدید --enable-preview می‌شود که در JEP 12 شرح داده شده است.

  • هیچ تمهیدی برای ارسال گزینه‌های اضافی دیگر به کامپایلر، مانند -processor یا -Werror، در نظر گرفته نشده است.
  • فایل‌های آرگومان خط فرمان (فایل‌های @) را می‌توان به شیوهٔ استاندارد استفاده کرد. فهرست‌های طولانی از آرگومان‌ها چه برای VM یا برای برنامه‌ای که فراخوانی می‌شود، می‌توانند درون فایل‌هایی قرار گیرند که با افزودن نویسهٔ @ به ابتدای نام فایل در خط فرمان مشخص می‌شوند.

در حالت فایل منبع، کامپایل به صورت زیر پیش می‌رود:

  • هرگونه گزینهٔ خط فرمان که به محیط کامپایل مربوط باشد در نظر گرفته می‌شود. این موارد شامل این گزینه‌ها هستند: --class-path/-classpath/-cp، --module-path/-p، --add-exports، --add-modules، --limit-modules، --patch-module، --upgrade-module-path، --enable-preview.
  • ریشهٔ درخت منبع، <source-root>، بر اساس پکیج کلاسی که راه‌اندازی می‌شود محاسبه می‌گردد. برای نمونه، اگر HelloWorld.java کلاس‌های خود را در پکیج hello اعلان کرده باشد، انتظار می‌رود که فایل HelloWorld.java در دایرکتوری somedir/hello/ قرار داشته باشد. در این حالت، somedir به عنوان ریشهٔ درخت منبع محاسبه می‌شود.
  • ریشهٔ درخت منبع به عنوان مسیر منبع (source-path) برای کامپایل عمل می‌کند، تا سایر فایل‌های منبع موجود در آن درخت که مورد نیاز HelloWorld هستند نیز بتوانند کامپایل شوند.
  • پردازش حاشیه‌نویسی‌ها (Annotation processing) غیرفعال است، درست مانند اینکه -proc:none اعمال شده باشد.
  • اگر نسخه‌ای از طریق گزینهٔ --source مشخص شده باشد، مقدار آن به عنوان آرگومان یک گزینهٔ ضمنی --release برای کامپایل استفاده می‌شود. این کار هم نسخهٔ منبع پذیرفته‌شده توسط کامپایلر و هم API سیستمی را که کد موجود در فایل منبع می‌تواند استفاده کند تنظیم می‌کند.
  • اگر --enable-preview مشخص شده باشد، می‌توان از آرگومان‌های --source N صرف‌نظر کرد. اگر نسخهٔ زمان اجرای Java برابر با N باشد، هنگام کامپایل فایل‌های منبع، --release N به صورت ضمنی اعمال می‌شود.
  • اگر فایلی به نام module-info.java در دایرکتوری <source-root> وجود داشته باشد، اعلان ماژول آن برای تعریف یک ماژول نام‌دار استفاده می‌شود که شامل تمام کلاس‌های کامپایل‌شده از فایل‌های .java در درخت منبع خواهد بود. اگر module-info.java وجود نداشته باشد، تمام کلاس‌های کامپایل‌شده از فایل‌های منبع در بستر یک ماژول بی‌نام (unnamed module) کامپایل خواهند شد.
  • فایل منبعی که راه‌اندازی می‌شود باید شامل یک یا چند کلاس سطح‌بالا (top-level) باشد که نخستین آن‌ها به عنوان کلاسی که باید اجرا شود در نظر گرفته می‌شود.
  • برای فایل منبعی که راه‌اندازی می‌شود، کامپایلر محدودیت اختیاری تعریف‌شده در انتهای JLS 7.6 را اعمال نمی‌کند؛ مبنی بر اینکه یک نوع (type) در یک پکیج نام‌دار باید در فایلی قرار داشته باشد که نام آن از نام آن نوع به‌همراه پسوند .java تشکیل شده است.
  • اگر یک فایل منبع دارای خطا باشد، پیام‌های خطای مناسب در جریان خطای استاندارد (standard error) نوشته می‌شوند و راه‌انداز با یک کد خروج غیرصفر خارج می‌شود.

در حالت فایل منبع، اجرا به صورت زیر پیش می‌رود:

  • کلاسی که باید اجرا شود نخستین کلاس سطح‌بالای یافت‌شده در فایل منبع است. این کلاس باید حاوی اعلان یک متد ورودی main باشد.
  • کلاس‌های کامپایل‌شده توسط یک بارگذار کلاس (class loader) سفارشی بارگذاری می‌شوند که کار را به بارگذار کلاس برنامه واگذار می‌کند. این بدان معناست که کلاس‌های موجود در مسیر کلاس برنامه (application class path) نمی‌توانند به هیچ‌یک از کلاس‌های تعریف‌شده در فایل‌های منبع ارجاع دهند.
  • اگر فایل module-info.java در دایرکتوری <source-root> وجود داشته باشد، آن‌گاه تمام کلاس‌های کامپایل‌شده از فایل‌های .java در درخت منبع درون آن ماژول قرار خواهند گرفت، که به عنوان ماژول ریشه برای اجرای برنامه عمل خواهد کرد. اگر module-info.java وجود نداشته باشد، کلاس‌های کامپایل‌شده در بستر یک ماژول بی‌نام اجرا می‌شوند، درست مانند اینکه --add-modules=ALL-DEFAULT اعمال شده باشد. این امر علاوه بر هر گزینهٔ --add-module دیگری است که ممکن است در خط فرمان مشخص شده باشد.
  • هر آرگومانی که در خط فرمان پس از نام فایل بیاید، به شیوهٔ معمول به متد main ارسال می‌شود.
  • اگر در مسیر کلاس برنامه کلاسی با نام یکسان با کلاسی که باید اجرا شود وجود داشته باشد، یک خطا محسوب می‌شود..PP برای جزئیات کامل، JEP 458: Launch Multi-File Source-Code Programs [https://openjdk.org/jeps/458] را ببینید.

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

برای دربرگرفتن آرگومان‌هایی که حاوی نویسه‌های فاصله‌خالی هستند، می‌توان از نقل‌قول تکی (') یا جفتی (") استفاده کرد. تمام محتوای بین نقل‌قول باز و نخستین نقل‌قول بستهٔ متناظر با آن، صرفاً با حذف جفت نقل‌قول حفظ می‌شود. در صورتی که نقل‌قول منطبق پیدا نشود، اجراکننده با یک پیام خطا متوقف خواهد شد. فایل‌های @ درست همان‌گونه که در خط فرمان تعیین می‌شوند، پشتیبانی می‌گردند. هیچ نویسهٔ عمومی صریح (*) در محتوای متغیر محیطی JDK_JAVA_OPTIONS بسط داده نمی‌شود و همان‌گونه که هست به VM آغازین تحویل داده می‌شود. به منظور کاهش سوءاستفاده‌های بالقوه از رفتار JDK_JAVA_OPTIONS، گزینه‌هایی که کلاس اصلی را مشخص می‌کنند (مانند -jar) یا باعث می‌شوند اجراکنندهٔ java بدون اجرای کلاس اصلی خارج شود (مانند -h) در متغیر محیطی مجاز نیستند. اگر هر یک از این گزینه‌ها در متغیر محیطی ظاهر شوند، اجراکننده با یک پیام خطا متوقف می‌شود. هنگامی که JDK_JAVA_OPTIONS تنظیم شده باشد، اجراکننده پیامی را به عنوان یادآوری در stderr چاپ می‌کند.

مثال:

$ export JDK_JAVA_OPTIONS='-g @file1 -Dprop=value @file2 -Dws.prop="white spaces"'
$ java -Xint @file3

معادل است با خط فرمان:

java -g @file1 -Dprop=value @file2 -Dws.prop="white spaces" -Xint @file3

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

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

استفاده از گزینه‌های پیشرفته برای مصارف عادی توصیه نمی‌شود. این‌ها گزینه‌های توسعه‌دهنده هستند که برای تنظیم بخش‌های خاصی از عملکرد ماشین مجازی Java HotSpot به کار می‌روند که اغلب نیازمندی‌های سیستمی خاصی داشته و ممکن است نیازمند دسترسی ویژه به پارامترهای پیکربندی سیستم باشند. چندین نمونه از تنظیم کارایی در Performance Tuning Examples ارائه شده است. پشتیبانی از این گزینه‌ها در تمامی پیاده‌سازی‌های JVM تضمین نشده است و در معرض تغییر هستند. گزینه‌های پیشرفته با -XX آغاز می‌شوند.

  • گزینه‌های پیشرفته زمان اجرا برای Java: رفتار زمان اجرای Java HotSpot VM را کنترل می‌کنند.
  • گزینه‌های پیشرفته کامپایلر JIT برای Java: کامپایل پویای در زمان اجرا (JIT) انجام‌شده توسط Java HotSpot VM را کنترل می‌کنند.
  • گزینه‌های پیشرفته قابلیت سرویس‌دهی برای Java: امکان جمع‌آوری اطلاعات سیستم و انجام اشکال‌زدایی گسترده را فراهم می‌سازند.
  • گزینه‌های پیشرفته بازیافت حافظه برای Java: نحوهٔ اجرای فرایند بازیافت حافظه (GC) را توسط Java HotSpot کنترل می‌کنند.

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

برای گزینه‌هایی که نیاز به یک آرگومان دارند، آرگومان ممکن است با فاصله، دو‌نقطه (:) یا علامت مساوی (=) از نام گزینه جدا شود، یا ممکن است آرگومان مستقیماً پس از گزینه بیاید (نحو دقیق برای هر گزینه متفاوت است). اگر از شما انتظار می‌رود اندازه را بر حسب بایت مشخص کنید، می‌توانید از هیچ پسوندی استفاده نکنید، یا از پسوند k یا K برای کیلوبایت (KB)، m یا M برای مگابایت (MB)، یا g یا G برای گیگابایت (GB) استفاده نمایید. برای مثال، جهت تنظیم اندازه روی ۸ گیگابایت، می‌توانید یکی از مقادیر 8g، 8192m، 8388608k یا 8589934592 را به عنوان آرگومان مشخص کنید. اگر از شما خواسته شده است که درصد را تعیین کنید، از عددی بین ۰ تا ۱ استفاده کنید. به عنوان مثال، برای ۲۵٪ مقدار 0.25 را مشخص کنید.

بخش‌های زیر گزینه‌های منسوخ‌شده، متروک و حذف‌شده را شرح می‌دهند:

  • گزینه‌های منسوخ‌شدهٔ Java: پذیرفته می‌شوند و روی آن‌ها عمل می‌شود --- هنگام استفاده از آن‌ها یک هشدار صادر می‌گردد.
  • گزینه‌های متروک Java: پذیرفته می‌شوند اما نادیده گرفته می‌شوند --- هنگام استفاده از آن‌ها یک هشدار صادر می‌گردد.
  • گزینه‌های حذف‌شدهٔ Java: حذف شده‌اند --- استفاده از آن‌ها منجر به خطا می‌شود..SH "گزینه‌های استاندارد برای جاوا (STANDARD OPTIONS FOR JAVA)" این‌ها پرکاربردترین گزینه‌هایی هستند که توسط تمامی پیاده‌سازی‌های JVM پشتیبانی می‌شوند.

نکته: برای مشخص کردن یک آرگومان برای یک گزینه بلند، می‌توانید از --name=value یا --name value استفاده کنید.

کتابخانه agent بومی (native) مشخص‌شده را بارگذاری می‌کند. پس از نام کتابخانه، می‌توان از فهرستی از گزینه‌های مخصوص به آن کتابخانه که با کاما جدا شده‌اند استفاده کرد. اگر گزینه -agentlib:foo مشخص شده باشد، JVM با استفاده از قراردادهای نام‌گذاری و مکان‌های خاص پلتفرم، تلاش می‌کند کتابخانه‌ای به نام foo را بارگذاری کند:
  • لینوکس و سایر پلتفرم‌های شبه‌پازیکس (POSIX-like): ماشین مجازی JVM تلاش می‌کند کتابخانه‌ای با نام libfoo.so را در مکان مشخص‌شده توسط متغیر سیستمی LD_LIBRARY_PATH بارگذاری کند.
  • سیستم‌عامل macOS: ماشین مجازی JVM تلاش می‌کند کتابخانه‌ای با نام libfoo.dylib را در مکان مشخص‌شده توسط متغیر سیستمی DYLD_LIBRARY_PATH بارگذاری کند.
  • ویندوز: ماشین مجازی JVM تلاش می‌کند کتابخانه‌ای با نام foo.dll را در مکان مشخص‌شده توسط متغیر سیستمی PATH بارگذاری کند.

مثال زیر نحوه بارگذاری کتابخانه Java Debug Wire Protocol (JDWP) و گوش دادن به اتصال سوکت روی پورت 8000 را نشان می‌دهد، که پیش از بارگذاری کلاس اصلی، JVM را متوقف (suspend) می‌کند:

-agentlib:jdwp=transport=dt_socket,server=y,address=8000

کتابخانه agent بومی مشخص‌شده با نام مسیر مطلق را بارگذاری می‌کند. این گزینه معادل -agentlib است، اما از مسیر کامل و نام فایل کتابخانه استفاده می‌کند.
فهرستی از دایرکتوری‌ها، فایل‌های JAR و آرشیوهای ZIP را برای جستجوی فایل‌های کلاس مشخص می‌کند.
در ویندوز، نقطه-ویرگول (;) موجودیت‌ها را در این فهرست جدا می‌کند؛ در سایر پلتفرم‌ها این کار با دونقطه (:) انجام می‌شود. مشخص کردن classpath بر هر مقداری از متغیر محیطی CLASSPATH تقدم دارد. اگر گزینه مسیر کلاس استفاده نشود و classpath تنظیم نشده باشد، مسیر کلاس کاربر شامل دایرکتوری جاری (.) خواهد بود. به‌عنوان یک تسهیل ویژه، مؤلفه‌ای از مسیر کلاس که نام پایه آن یک ستاره (*) باشد، معادل مشخص کردن فهرستی از تمام فایل‌های درون دایرکتوری با پسوند .jar یا .JAR تلقی می‌شود. یک برنامه جاوا تفاوتی بین این دو روش فراخوانی مشاهده نمی‌کند. برای مثال، اگر دایرکتوری mydir شامل a.jar و b.JAR باشد، مؤلفه مسیر کلاس mydir/* به A.jar:b.JAR بسط داده می‌شود، با این تفاوت که ترتیب فایل‌های JAR نامشخص است. تمام فایل‌های .jar موجود در دایرکتوری مشخص‌شده، حتی موارد پنهان، در فهرست گنجانده می‌شوند. یک مدخل مسیر کلاس متشکل از یک ستاره (*) به فهرستی از تمام فایل‌های jar در دایرکتوری جاری بسط می‌یابد. متغیر محیطی CLASSPATH نیز، در صورت تعریف، به‌طور مشابهی بسط می‌یابد. هرگونه بسط نویسه‌های عام (wildcard) در مسیر کلاس پیش از آغاز به کار Java VM رخ می‌دهد. برنامه‌های جاوا هرگز نویسه‌های عامی را که بسط نیافته‌اند مشاهده نمی‌کنند، مگر با پرس‌وجو از محیط، مانند فراخوانی System.getenv("CLASSPATH").
می‌تواند در هر کجای خط فرمان، از جمله درون یک فایل آرگومان، استفاده شود تا از بسط بیشتر @filename جلوگیری کند. این گزینه بسط فایل‌های آرگومان @-argfiles بعد از این گزینه را متوقف می‌کند.
به کلاس‌ها اجازه می‌دهد به ویژگی‌های پیش‌نمایش (preview features) [https://docs.oracle.com/en/java/javase/12/language/index.html#JSLAN-GUID-5A82FE0E-0CA4-4F1F-B075-564874FE2823] این نسخه وابسته باشند.
دسترسی بومی (Native access) شامل دسترسی به کد یا داده‌های خارج از محیط زمان اجرای جاوا (Java runtime) است. این کار عموماً ناامن است و در صورت اجرای نادرست ممکن است به کرش JVM یا خرابی حافظه منجر شود. دسترسی بومی می‌تواند در نتیجه فراخوانی متدی رخ دهد که یا محدودشده (restricted) [https://openjdk.org/jeps/454#Safety] باشد، یا native. این گزینه به کدهای موجود در ماژول‌های مشخص‌شده اجازه دسترسی بومی را می‌دهد. دسترسی بومی رخ‌داده در ماژولی که صراحتاً فعال نشده باشد، غیرمجاز (illegal) تلقی می‌شود.
module می‌تواند نام یک ماژول، یا ALL-UNNAMED برای اشاره به کدهای موجود در مسیر کلاس باشد.
این گزینه نحوه مدیریت دسترسی بومی غیرمجاز را مشخص می‌کند:

نکته: این گزینه در نسخه‌های آینده حذف خواهد شد.

  • allow: این حالت اجازه دسترسی بومی غیرمجاز را در تمام ماژول‌ها، بدون انتشار هیچ هشداری می‌دهد.
  • warn: این حالت مشابه allow است، جز اینکه برای نخستین دسترسی بومی غیرمجاز مشاهده‌شده در یک ماژول، یک پیام هشدار صادر می‌شود. این حالت در JDK فعلی پیش‌فرض است اما در نسخه‌های آینده تغییر خواهد کرد.
  • deny: این حالت دسترسی بومی غیرمجاز را غیرفعال می‌کند. بدین صورت که هر دسترسی بومی غیرمجاز موجب بروز یک IllegalCallerException می‌شود. این حالت در نسخه‌های آینده به عنوان پیش‌فرض در نظر گرفته خواهد شد. برای اطمینان از آماده بودن برنامه خود برای نسخه‌های آینده JDK، آن را با --illegal-native-access=deny همراه با هر گزینه --enable-native-access لازم اجرا کنید.
تغییر دادن (Mutation) فیلدهای final از طریق reflection API در پلتفرم جاوا امکان‌پذیر است. با این وجود، این کار ایمنی و کارایی را در تمام برنامه‌ها به خطر می‌اندازد. این گزینه به کدهای موجود در ماژول‌های مشخص‌شده اجازه می‌دهد فیلدهای final را از طریق بازتاب تغییر دهند. تلاش کدها در هر ماژول دیگری برای تغییر فیلدهای final از طریق بازتاب، غیرمجاز (illegal) محسوب می‌شود.
module می‌تواند نام یک ماژول در مسیر ماژول، یا ALL-UNNAMED برای اشاره به کدهای موجود در مسیر کلاس باشد.
این گزینه نحوه مدیریت تغییر غیرمجاز فیلدهای final را مشخص می‌کند:

نکته: این گزینه در نسخه‌های آینده حذف خواهد شد.

  • allow: این حالت اجازه تغییر غیرمجاز فیلدهای final را در تمام ماژول‌ها، بدون انتشار هیچ هشداری می‌دهد.
  • warn: این حالت مشابه allow است، به جز اینکه برای نخستین تغییر غیرمجاز فیلد final صورت‌گرفته در یک ماژول، یک پیام هشدار صادر می‌شود. این حالت در JDK فعلی پیش‌فرض است اما در نسخه‌های آینده تغییر خواهد کرد.
  • debug: این حالت مشابه allow است، با این تفاوت که برای هر تغییر غیرمجاز فیلد final، یک پیام هشدار و ردگیری پشته (stack trace) چاپ می‌شود.
  • deny: این حالت تغییر فیلدهای final را غیرفعال می‌کند. بدین صورت که هر دسترسی برای تغییر غیرمجاز فیلد final موجب بروز یک IllegalAccessException می‌شود. این حالت در نسخه‌های آینده به عنوان پیش‌فرض در نظر گرفته خواهد شد. برای اطمینان از آماده بودن برنامه خود برای نسخه‌های آینده JDK، آن را با --illegal-final-field-mutation=deny همراه با هر گزینه --enable-final-field-mutation لازم اجرا کنید.
انجام فرایند نهایی‌سازی (finalization) اشیاء را توسط JVM کنترل می‌کند. مقادیر معتبر شامل "enabled" و "disabled" هستند. نهایی‌سازی به‌طور پیش‌فرض فعال است، بنابراین مقدار "enabled" هیچ اثری ندارد. مقدار "disabled" نهایی‌سازی را غیرفعال می‌کند تا هیچ نهایی‌سازی (finalizer) فراخوانی نشود..TP --module-path modulepath... یا -p modulepath محل یافتن ماژول‌های برنامه را با فهرستی از عناصر مسیر مشخص می‌کند. عناصر یک مسیر ماژول می‌توانند مسیر فایلی به یک ماژول یا دایرکتوری‌ای حاوی ماژول‌ها باشند. هر ماژول یا یک JAR ماژولار است یا یک دایرکتوری ماژول بازشده (exploded-module).
در Windows، نقطه-ویرگول (;) عناصر مسیر را در این فهرست جدا می‌کند؛ در سایر پلتفرم‌ها این جداکننده دو‌نقطه (:) است.
محل یافتن ماژول‌های جایگزین برای ماژول‌های ارتقا‌پذیر در تصویر زمان اجرا (runtime image) را با فهرستی از عناصر مسیر مشخص می‌کند. عناصر یک مسیر ماژول می‌توانند مسیر فایلی به یک ماژول یا دایرکتوری‌ای حاوی ماژول‌ها باشند. هر ماژول یا یک JAR ماژولار است یا یک دایرکتوری ماژول بازشده (exploded-module).
در Windows، نقطه-ویرگول (;) عناصر مسیر را در این فهرست جدا می‌کند؛ در سایر پلتفرم‌ها این جداکننده دو‌نقطه (:) است.
علاوه بر ماژول اولیه، ماژول‌های ریشه را برای رفع وابستگی مشخص می‌کند. module همچنین می‌تواند ALL-DEFAULT، ALL-SYSTEM و ALL-MODULE-PATH باشد.
ماژول‌های قابل‌مشاهده را فهرست کرده و سپس خارج می‌شود.
یک ماژول مشخص‌شده را توصیف کرده و سپس خارج می‌شود.
ماشین مجازی (VM) را ایجاد می‌کند اما متد اصلی (main) را اجرا نمی‌کند. این گزینهٔ --dry-run می‌تواند برای اعتبارسنجی گزینه‌های خط فرمان مانند پیکربندی سیستم ماژول مفید باشد.
تمام ماژول‌ها را اعتبارسنجی کرده و خارج می‌شود. این گزینه برای یافتن تداخل‌ها و سایر خطاهای ماژول‌های موجود در مسیر ماژول مفید است.
مقدار یک ویژگی سیستمی را تنظیم می‌کند. متغیر property رشته‌ای بدون فاصله است که نام ویژگی را نشان می‌دهد. متغیر value رشته‌ای است که مقدار ویژگی را نشان می‌دهد. اگر value رشته‌ای حاوی فاصله است، آن را داخل علامت نقل‌قول قرار دهید (برای مثال -Dfoo="foo bar";).
گزاره‌های شرطی بررسی صحت (assertions) را غیرفعال می‌کند. به‌طور پیش‌فرض، assertionها در همهٔ بسته‌ها و کلاس‌ها غیرفعال هستند. بدون آرگومان، -disableassertions (-da) assertionها را در تمام بسته‌ها و کلاس‌ها غیرفعال می‌کند. با آرگومان packagename که به ... ختم می‌شود، این سوییچ assertionها را در بستهٔ مشخص‌شده و تمامی زیربسته‌های آن غیرفعال می‌کند. اگر آرگومان صرفاً ... باشد، سوییچ assertionها را در بستهٔ بی‌نام در دایرکتوری کاری فعلی غیرفعال می‌کند. با آرگومان classname، این سوییچ assertionها را در کلاس مشخص‌شده غیرفعال می‌کند.
گزینهٔ -disableassertions (-da) بر تمامی بارگذارهای کلاس و کلاس‌های سیستمی (که بارگذار کلاس ندارند) اعمال می‌شود. یک استثنا برای این قاعده وجود دارد: اگر این گزینه بدون هیچ آرگومانی ارائه شود، بر کلاس‌های سیستمی اعمال نخواهد شد. این امر غیرفعال کردن assertionها را در تمام کلاس‌ها به‌جز کلاس‌های سیستمی آسان می‌کند. گزینهٔ -disablesystemassertions به شما امکان می‌دهد تا assertionها را در تمام کلاس‌های سیستمی غیرفعال کنید. جهت فعال‌سازی صریح assertionها در بسته‌ها یا کلاس‌های مشخص، از گزینهٔ -enableassertions (-ea) استفاده کنید. هر دو گزینه می‌توانند به‌طور هم‌زمان استفاده شوند. برای مثال، جهت اجرای برنامهٔ MyClass با assertionهای فعال در بستهٔ com.wombat.fruitbat (و هر یک از زیربسته‌های آن) اما غیرفعال در کلاس com.wombat.fruitbat.Brickbat، از دستور زیر استفاده کنید:

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

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

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

assertionها را در تمام کلاس‌های سیستمی فعال می‌کند.
پیام راهنما را در جریان خطا چاپ می‌کند.
پیام راهنما را در جریان خروجی چاپ می‌کند.
عامل (agent) مشخص‌شدهٔ زبان برنامه‌نویسی Java را بارگذاری می‌کند. ببینید: java.lang.instrument.
نسخهٔ محصول را در جریان خروجی چاپ کرده و ادامه می‌دهد.
نسخهٔ محصول را در جریان خطا چاپ کرده و ادامه می‌دهد.
خروجی رفع وابستگی ماژول را در حین راه‌اندازی نمایش می‌دهد.
صفحهٔ آغازین (splash screen) را با تصویر مشخص‌شده با imagepath نمایش می‌دهد. تصاویر مقیاس‌بندی‌شدهٔ HiDPI به‌طور خودکار پشتیبانی شده و در صورت موجود بودن استفاده می‌شوند. نام فایل تصویر بدون مقیاس، مانند image.ext، باید همیشه به‌عنوان آرگومان به گزینهٔ -splash داده شود. مناسب‌ترین تصویر مقیاس‌بندی‌شدهٔ ارائه‌شده به‌طور خودکار انتخاب می‌شود.
برای مثال، جهت نمایش فایل splash.gif از دایرکتوری images هنگام شروع برنامه‌تان، از گزینهٔ زیر استفاده کنید:

-splash:images/splash.gif

برای اطلاعات بیشتر به مستندات SplashScreen API مراجعه کنید.
اطلاعات مربوط به هر کلاس بارگذاری‌شده را نمایش می‌دهد.
اطلاعات مربوط به هر رویداد جمع‌آوری زباله (GC) را نمایش می‌دهد.
اطلاعات مربوط به استفاده از متدهای native و سایر فعالیت‌های Java Native Interface (JNI) را نمایش می‌دهد.
اطلاعات مربوط به ماژول‌های در حال استفاده را نمایش می‌دهد.
نسخهٔ محصول را در جریان خروجی چاپ کرده و خارج می‌شود.
نسخهٔ محصول را در جریان خطا چاپ کرده و خارج می‌شود..TP -X راهنمای گزینه‌های اضافی را در جریان خطا چاپ می‌کند.
راهنمای گزینه‌های اضافی را در جریان خروجی چاپ می‌کند.
@argfile
یک یا چند فایل آرگومان با پیشوند @ را مشخص می‌کند که توسط دستور java استفاده می‌شوند. بسیار معمول است که خط فرمان java به دلیل فایل‌های .jar مورد نیاز در classpath بسیار طولانی باشد. گزینهٔ @argfile با توانمندسازی اجراکننده برای بسط دادن محتویات فایل‌های آرگومان پس از بسط پوسته (shell expansion) اما پیش از پردازش آرگومان‌ها، بر محدودیت‌های طول خط فرمان غلبه می‌کند. محتویات درون فایل‌های آرگومان بسط می‌یابند، زیرا در غیر این صورت، تا زمانی که گزینهٔ --disable-@files دیده نشود، در خط فرمان تعیین می‌شدند.
فایل‌های آرگومان همچنین می‌توانند شامل نام کلاس اصلی و تمامی گزینه‌ها باشند. اگر یک فایل آرگومان شامل تمام گزینه‌های مورد نیاز دستور java باشد، خط فرمان می‌تواند به سادگی به شکل زیر باشد:

java @argfile

برای توضیحات و مثال‌های استفاده از @-argfiles، بخش java Command-Line Argument Files را ببینید.

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

کامپایل در پس‌زمینه را غیرفعال می‌کند. به‌طور پیش‌فرض، JVM متد را به عنوان یک وظیفه در پس‌زمینه کامپایل می‌کند و تا زمان اتمام کامپایل در پس‌زمینه، متد را در حالت مفسر اجرا می‌نماید. پرچم -Xbatch کامپایل پس‌زمینه را غیرفعال می‌کند تا کامپایل تمام متدها به عنوان وظیفه‌ای در پیش‌زمینه تا زمان تکمیل ادامه یابد. این گزینه معادل با -XX:-BackgroundCompilation است.
فهرستی از دایرکتوری‌ها، فایل‌های JAR و آرشیوهای ZIP را جهت الحاق به انتهای مسیر کلاس راه‌اندازی پیش‌فرض (bootstrap class path) مشخص می‌کند.
در ویندوز، نقطه ویرگول (;) موجودیت‌ها را در این فهرست جدا می‌کند؛ در سایر سیستم‌عامل‌ها این کار با دونقطه (:) انجام می‌شود.
بررسی‌های اضافی را برای توابع واسط بومی جاوا (JNI) انجام می‌دهد.
بررسی‌های زیر نشان‌دهندهٔ مشکلات اساسی در کد بومی (native) تلقی می‌شوند و در چنین مواردی JVM با یک خطای غیرقابل جبران به کار خود پایان می‌دهد:
  • نخی (thread) که فراخوانی را انجام می‌دهد به JVM متصل نشده باشد.
  • نخی که فراخوانی را انجام می‌دهد از JNIEnv متعلق به نخ دیگری استفاده کند.
  • یک بررسی اعتبارسنجی پارامتر با شکست مواجه شود:
•
یک jfieldID یا jmethodID نامعتبر تشخیص داده شود. به عنوان مثال:
  • از نوع نادرست باشد
  • به کلاس نادرستی مرتبط شده باشد
  • پارامتری با نوع نادرست تشخیص داده شود.
  • مقدار نامعتبری برای یک پارامتر تشخیص داده شود. به عنوان مثال:
  • مقدار NULL در جایی که مجاز نیست
  • اندیس خارج از محدودهٔ آرایه، یا ظرفیت فریم
  • یک رشتهٔ غیر UTF-8
  • یک ارجاع نامعتبر JNI
  • تلاش برای استفاده از یک تابع ReleaseXXX روی پارامتری که توسط تابع متناظر GetXXX تولید نشده است
بررسی‌های زیر تنها منجر به چاپ هشدار می‌شوند:
  • یک فراخوانی JNI بدون بررسی استثنای معلق از فراخوانی قبلی JNI انجام شده باشد، در حالی که فراخوانی فعلی هنگام وجود استثنای معلق ایمن نیست.
  • یک توصیف‌گر کلاس در قالب تزیین‌شده (Lname;) باشد، در حالی که نباید باشد.
  • پارامتر NULL مجاز است، اما استفاده از آن جای سؤال دارد.
  • فراخوانی سایر توابع JNI در محدودهٔ Get/ReleasePrimitiveArrayCritical یا Get/ReleaseStringCritical.
  • یک فراخوانی JNI برای تغییر دادن یک فیلد final انجام شده باشد. هنگام استفاده از این گزینه، انتظار کاهش کارایی را داشته باشید.
حالت آزمایشی برای به کار انداختن کامپایلرهای JIT. این گزینه نباید در محیط‌های عملیاتی (production) استفاده شود.
هیچ کاری انجام نمی‌دهد؛ برای حذف در انتشار‌های آینده منسوخ شده است.
پیام‌های تشخیصی اضافی را نمایش می‌دهد.
برنامه را فقط در حالت تفسیری اجرا می‌کند. کامپایل به کد بومی غیرفعال شده و تمام بایت‌کد توسط مفسر اجرا می‌شود. مزایای کارایی ارائه‌شده توسط کامپایلر درجا (JIT) در این حالت وجود ندارد.
اطلاعات دقیق‌تری از نسخهٔ JVM را نسبت به گزینهٔ -version نمایش می‌دهد و سپس خارج می‌شود.
پیکربندی یا فعال‌سازی گزارش‌گیری با چارچوب گزارش‌گیری یکپارچهٔ ماشین مجازی جاوا (JVM). بخش Enable Logging with the JVM Unified Logging Framework را ببینید.
تمام بایت‌کد را توسط مفسر اجرا می‌کند، به جز متدهای پرکاربرد (hot methods) که به کد بومی کامپایل می‌شوند. به‌طور پیش‌فرض فعال است. برای غیرفعال کردن از -Xint استفاده کنید.
اندازهٔ اولیه و حداکثر اندازه (به بایت) هیپ را برای نسل جوان (nursery) در زباله‌روب‌های نسلی تنظیم می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M برای مگابایت، یا g یا G برای گیگابایت ضمیمه کنید. ناحیهٔ نسل جوان از هیپ برای اشیاء جدید استفاده می‌شود. فرایند GC در این ناحیه بیشتر از سایر نواحی انجام می‌گیرد. اگر اندازهٔ نسل جوان خیلی کوچک باشد، تعداد زیادی زباله‌روبی جزئی (minor GC) انجام می‌شود. اگر اندازه بیش از حد بزرگ باشد، فقط زباله‌روبی‌های کامل (full GC) انجام می‌شوند که ممکن است زمان زیادی به طول بینجامند. توصیه می‌شود که اندازهٔ نسل جوان را برای زباله‌روب G1 تنظیم نکنید، و برای سایر زباله‌روب‌ها، اندازهٔ آن را بیشتر از ۲۵٪ و کمتر از ۵۰٪ اندازهٔ کلی هیپ نگه دارید. مثال‌های زیر نحوهٔ تنظیم اندازهٔ اولیه و حداکثر اندازهٔ نسل جوان را روی ۲۵۶ مگابایت با استفاده از واحدهای مختلف نشان می‌دهند:
-Xmn256m
-Xmn262144k
-Xmn268435456
به جای استفاده از گزینهٔ -Xmn برای تنظیم هم‌زمان اندازهٔ اولیه و حداکثر اندازهٔ هیپ برای نسل جوان، می‌توانید از -XX:NewSize برای تنظیم اندازهٔ اولیه و از -XX:MaxNewSize برای تنظیم حداکثر اندازه استفاده کنید.
حداقل و اندازهٔ اولیهٔ هیپ (به بایت) را تنظیم می‌کند. این مقدار باید مضربی از ۱۰۲۴ و بزرگ‌تر از ۱ مگابایت باشد. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M برای مگابایت، یا g یا G برای گیگابایت ضمیمه کنید. مثال‌های زیر نحوهٔ تنظیم اندازهٔ حافظهٔ تخصیص‌یافته را روی ۶ مگابایت با استفاده از واحدهای مختلف نشان می‌دهند: 
-Xms6291456
-Xms6144k
-Xms6m
اگر این گزینه را تنظیم نکنید، اندازه اولیه برابر با مجموع اندازه‌های تخصیص‌یافته به نسل قدیم (old generation) و نسل جوان (young generation) تعیین می‌شود. اندازه اولیه هیپ برای نسل جوان را می‌توان با استفاده از گزینه -Xmn یا گزینه -XX:NewSize تنظیم کرد. توجه داشته باشید که از گزینه -XX:InitialHeapSize نیز می‌توان برای تنظیم اندازه اولیه هیپ استفاده کرد. اگر این گزینه پس از -Xms در خط فرمان بیاید، اندازه اولیه هیپ روی مقدار مشخص‌شده با -XX:InitialHeapSize تنظیم می‌شود.

حداکثر اندازه (به بایت) هیپ را مشخص می‌کند. این مقدار باید مضربی از ۱۰۲۴ و بزرگ‌تر از ۲ مگابایت باشد. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، یا g یا G را برای گیگابایت اضافه کنید. مقدار پیش‌فرض در زمان اجرا بر اساس پیکربندی سیستم انتخاب می‌شود. برای استقرار در محیط‌های سرور، معمولاً -Xms و -Xmx روی مقدار یکسانی تنظیم می‌شوند. مثال‌های زیر نحوه تعیین حداکثر اندازه مجاز حافظه تخصیص‌یافته به ۸۰ مگابایت را با استفاده از واحدهای مختلف نشان می‌دهند:
-Xmx83886080
-Xmx81920k
-Xmx80m
گزینه -Xmx معادل -XX:MaxHeapSize است.
جمع‌آوری زباله (GC) مربوط به کلاس‌ها را غیرفعال می‌کند. این کار می‌تواند در زمان GC صرفه‌جویی کرده و وقفه‌ها را در حین اجرای برنامه کاهش دهد. هنگامی که -Xnoclassgc را هنگام راه‌اندازی مشخص می‌کنید، شیءهای کلاس (class objects) در برنامه در طول فرایند GC دست‌نخورده باقی می‌مانند و همواره زنده در نظر گرفته می‌شوند. این امر می‌تواند به اشغال دائمی بخش بیشتری از حافظه منجر شود که در صورت عدم استفاده محتاطانه، موجب بروز استثنای کمبود حافظه (out-of-memory) خواهد شد.
استفاده از سیگنال‌های سیستم‌عامل توسط JVM را کاهش می‌دهد. قلاب‌های خاموش‌سازی (shutdown hooks) امکان خروج منظم برنامه جاوا را با اجرای کد پاک‌سازی کاربر (مانند بستن اتصالات پایگاه داده) در هنگام خاموش‌سازی فراهم می‌کنند، حتی اگر JVM به طور ناگهانی خاتمه یابد.
•
سیستم‌های غیر ویندوز (Non-Windows):
  • ماشین JVM سیگنال‌ها را به دام می‌اندازد تا قلاب‌های خاموش‌سازی را در شرایط خاتمه غیرمنتظره اجرا کند. ماشین JVM از سیگنال‌های SIGHUP، SIGINT و SIGTERM برای آغاز اجرای قلاب‌های خاموش‌سازی استفاده می‌کند.
  • برنامه‌هایی که JVM را درون خود تعبیه می‌کنند، معمولاً نیاز به رهگیری سیگنال‌هایی نظیر SIGINT یا SIGTERM دارند که می‌تواند منجر به تداخل با گرداننده‌های سیگنال (signal handlers) ماشین JVM شود. گزینه -Xrs برای رفع این مسئله در نظر گرفته شده است. هنگام استفاده از -Xrs، ماسک‌های سیگنال برای SIGINT، SIGTERM، SIGHUP و SIGQUIT توسط JVM تغییر داده نمی‌شوند و گرداننده‌ای برای این سیگنال‌ها نصب نمی‌گردد.
•
ویندوز (Windows):
  • ماشین JVM رویدادهای کنترلی کنسول را زیر نظر می‌گیرد تا قلاب‌های خاموش‌سازی را برای خاتمه‌های غیرمنتظره پیاده‌سازی کند. به طور مشخص، JVM یک گرداننده کنترلی کنسول ثبت می‌کند که پردازش قلاب خاموش‌سازی را آغاز کرده و برای رویدادهای CTRL_C_EVENT، CTRL_CLOSE_EVENT، CTRL_LOGOFF_EVENT و CTRL_SHUTDOWN_EVENT مقدار TRUE برمی‌گرداند.
  • ماشین JVM از سازوکار مشابهی برای پیاده‌سازی قابلیت تخلیه پشته ریسه‌ها (thread dumps) جهت مقاصد اشکال‌زدایی استفاده می‌کند. ماشین JVM برای انجام تخلیه ریسه‌ها از CTRL_BREAK_EVENT بهره می‌برد.
  • اگر JVM به عنوان یک سرویس اجرا شود (مثلاً به عنوان موتور سرولت برای یک وب‌سرور)، ممکن است CTRL_LOGOFF_EVENT را دریافت کند، اما نباید فرایند خاموش‌سازی را آغاز نماید؛ زیرا سیستم‌عامل در واقع فرایند را خاتمه نمی‌دهد. جهت اجتناب از تداخل‌های احتمالی نظیر این، می‌توان از گزینه -Xrs استفاده کرد. هنگامی که گزینه -Xrs به کار می‌رود، JVM هیچ گرداننده کنترل کنسولی نصب نمی‌کند؛ بدین معنی که رویدادهای CTRL_C_EVENT، CTRL_CLOSE_EVENT، CTRL_LOGOFF_EVENT یا CTRL_SHUTDOWN_EVENT را زیر نظر نمی‌گیرد و پردازش نمی‌کند.
مشخص کردن -Xrs دو پیامد به همراه دارد:
  • سیستم‌های غیر ویندوز (Non-Windows): تخلیه پشته ریسه با SIGQUIT در دسترس نخواهد بود.
  • ویندوز (Windows): تخلیه پشته ریسه با Ctrl + Break در دسترس نخواهد بود. اجرای قلاب‌های خاموش‌سازی بر عهده کد کاربر است، برای مثال از طریق فراخوانی System.exit() در زمانی که قرار است JVM خاتمه یابد.
حالت اشتراک‌گذاری داده‌های کلاس (CDS) را تنظیم می‌کند.
آرگومان‌های ممکن mode برای این گزینه عبارتند از:
استفاده از داده‌های کلاس مشترک در صورت امکان (پیش‌فرض).
الزام در استفاده از داده‌های کلاس مشترک، در غیر این صورت با شکست مواجه می‌شود.

توجه: گزینه -Xshare:on فقط برای مقاصد آزمایشی استفاده می‌شود. این گزینه در صورتی که بایگانی CDS قابل استفاده نباشد (مثلاً هنگام تغییر برخی پارامترهای مشخص VM، یا هنگام استفاده از یک JDK متفاوت)، ممکن است باعث خروج غیرمنتظره ماشین مجازی در هنگام راه‌اندازی شود. این گزینه نباید در محیط‌های عملیاتی استفاده شود.

هیچ تلاشی برای استفاده از داده‌های کلاس مشترک انجام نمی‌دهد.
همه تنظیمات را نمایش داده و سپس ادامه می‌دهد.
تنظیمات را نمایش داده و ادامه می‌دهد. آرگومان‌های ممکن category برای این گزینه عبارتند از:
تمام دسته‌های تنظیمات را با جزئیات کامل (verbose) نشان می‌دهد.
تنظیمات مربوط به محلی‌سازی (locale) را نمایش می‌دهد.
تنظیمات مربوط به ویژگی‌های سیستم (system properties) را نمایش می‌دهد.
تمام تنظیمات مربوط به امنیت را نمایش می‌دهد.
آرگومان‌های زیردسته برای security شامل موارد زیر است:
  • security:all : تمام تنظیمات امنیتی را نشان می‌دهد
  • security:properties : ویژگی‌های امنیتی را نشان می‌دهد
  • security:providers : تنظیمات ارائه‌دهنده امنیتی ایستا را نشان می‌دهد
  • security:tls : تنظیمات امنیتی مربوط به TLS را نشان می‌دهد
تنظیمات JVM را نمایش می‌دهد.
فقط در لینوکس: پیکربندی سیستم میزبان یا کانتینر را نشان داده و ادامه می‌دهد.
اندازه پشته ریسه (thread stack) را (به بایت) تنظیم می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، یا g یا G را برای گیگابایت اضافه کنید. اندازه واقعی ممکن است بر اساس الزامات سیستم‌عامل، به مضربی از اندازه صفحه حافظه (page size) سیستم به سمت بالا گرد شود. مقدار پیش‌فرض به بستر اجرایی (پلتفرم) بستگی دارد. برای مثال: Linux/x64: 1024 KB
  • Linux/Aarch64: 2048 KB
  • macOS/x64: 1024 KB
  • macOS/Aarch64: 2048 KB
  • ویندوز: مقدار پیش‌فرض به حافظه مجازی بستگی دارد. مثال‌های زیر اندازه پشته ریسه (thread stack) را در واحدهای مختلف روی 1024 KB تنظیم می‌کنند:
-Xss1m
-Xss1024k
-Xss1048576
این گزینه مشابه -XX:ThreadStackSize است.

ماژول module را به‌روزرسانی می‌کند تا بدون در نظر گرفتن اعلان ماژول، target-module را بخواند. target-module می‌تواند برای خواندن تمام ماژول‌های بدون نام، برابر با ALL-UNNAMED باشد.
ماژول module را به‌روزرسانی می‌کند تا بدون در نظر گرفتن اعلان ماژول، پکیج package را به target-module صادر (export) کند. target-module می‌تواند برای صادر کردن به تمام ماژول‌های بدون نام، برابر با ALL-UNNAMED باشد.
ماژول module را به‌روزرسانی می‌کند تا بدون در نظر گرفتن اعلان ماژول، پکیج package را برای target-module باز (open) کند.
محدوده جهان ماژول‌های قابل مشاهده را تعیین می‌کند.
یک ماژول را با کلاس‌ها و منابع موجود در فایل‌های JAR یا دایرکتوری‌ها بازنویسی یا تکمیل می‌کند.
نسخه مبدأ را در حالت source-file تعیین می‌کند.
استفاده از رابط برنامه‌نویسی (API) پشتیبانی‌نشده sun.misc.Unsafe را مجاز یا رد می‌کند. مقدار value یکی از موارد زیر است:
اجازه استفاده از متدهای دسترسی به حافظه را بدون هیچ هشداری در زمان اجرا می‌دهد.
اجازه استفاده از متدهای دسترسی به حافظه را می‌دهد، اما در اولین باری که هرگونه متد دسترسی به حافظه استفاده شود، یک هشدار صادر می‌کند. حداکثر یک هشدار صادر خواهد شد.
اجازه استفاده از متدهای دسترسی به حافظه را می‌دهد، اما هنگام استفاده از هر متد دسترسی به حافظه، یک هشدار تک‌خطی و یک ردگیری پشته (stack trace) صادر می‌کند.
استفاده از متدهای دسترسی به حافظه را با پرتاب یک UnsupportedOperationException در هر بار استفاده منع می‌کند. مقدار پیش‌فرض در صورت مشخص نشدن گزینه، warn است.

گزینه‌های اضافی زیر مختص macOS هستند.

متد main() را روی اولین ریسه (AppKit) اجرا می‌کند.
نام پیش‌فرض برنامه را که در داک (dock) نمایش داده می‌شود بازنویسی می‌کند.
آیکون پیش‌فرض نمایش داده شده در داک را بازنویسی می‌کند..SH "گزینه‌های پیشرفته برای جاوا (ADVANCED OPTIONS FOR JAVA)" از این گزینه‌های java می‌توان برای فعال‌سازی سایر گزینه‌های پیشرفته استفاده کرد.
گزینه‌های در نظر گرفته شده برای عیب‌یابی JVM را فعال و باز می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و گزینه‌های عیب‌یابی در دسترس نیستند.
گزینه‌های خط فرمانی که با استفاده از این گزینه فعال می‌شوند، پشتیبانی نمی‌شوند. اگر هنگام استفاده از هر یک از این گزینه‌ها با مشکلی مواجه شوید، بسیار محتمل است که پیش از کمک پشتیبانی Oracle برای بررسی، از شما خواسته شود مشکل را بدون استفاده از این گزینه‌های پشتیبانی‌نشده بازتولید کنید. همچنین این احتمال وجود دارد که هر یک از این گزینه‌ها بدون هیچ‌گونه هشدار قبلی حذف شوند یا رفتار آن‌ها تغییر کند.
گزینه‌هایی را که ویژگی‌های آزمایشی را در JVM ارائه می‌دهند، فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و ویژگی‌های آزمایشی در دسترس نیستند.

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

تعداد پردازنده‌هایی (CPU) را که ماشین مجازی برای محاسبه اندازه استخرهای ریسه (thread pools) جهت عملیات گوناگون مانند Garbage Collection و ForkJoinPool استفاده می‌کند، رونویسی (override) می‌کند.
ماشین مجازی معمولاً تعداد پردازنده‌های دردسترس را از سیستم‌عامل به دست می‌آورد. این پرچم می‌تواند برای تقسیم‌بندی منابع CPU هنگام اجرای چندین فرایند جاوا در کانتینرهای docker مفید باشد. این پرچم حتی اگر UseContainerSupport فعال نباشد نیز رعایت می‌شود. برای توضیحات مربوط به فعال‌سازی و غیرفعال‌سازی پشتیبانی از کانتینر، -XX:-UseContainerSupport را ببینید.
مسیری به سیستم‌فایل را دریافت کرده و از نگاشت حافظه (memory mapping) برای تخصیص هیپ شیء (object heap) روی دستگاه حافظه استفاده می‌کند. استفاده از این گزینه HotSpot VM را قادر می‌سازد تا هیپ شیء جاوا را روی یک دستگاه حافظه جایگزین که توسط کاربر مشخص شده است، مانند NV-DIMM، تخصیص دهد.
دستگاه‌های حافظه جایگزینی که معناشناسی مشابهی با DRAM دارند، از جمله معناشناسی عملیات اتمیک (atomic operations)، می‌توانند بدون نیاز به تغییر کد برنامه موجود، به جای DRAM برای هیپ شیء به کار روند. سایر ساختارهای حافظه (مانند code heap، metaspace و پشته‌های ریسه) همچنان در DRAM مستقر خواهند ماند. برخی از سیستم‌عامل‌ها حافظه‌های غیر DRAM را از طریق سیستم‌فایل ارائه می‌دهند. فایل‌های نگاشت‌شده به حافظه در این سیستم‌فایل‌ها، حافظه نهان صفحه (page cache) را دور زده و یک نگاشت مستقیم از حافظه مجازی به حافظه فیزیکی روی دستگاه فراهم می‌کنند. پرچم‌های موجود مربوط به هیپ (مانند -Xmx و -Xms) و پرچم‌های مربوط به بازیافت حافظه (garbage collection) مانند قبل به عملکرد خود ادامه می‌دهند.
ویژگی Compact Strings را غیرفعال می‌کند. به‌طور پیش‌فرض، این گزینه فعال است. هنگامی که این گزینه فعال باشد، رشته‌های جاوا که فقط حاوی نویسه‌های تک‌بایتی هستند، در داخل به‌صورت رشته‌های تک‌بایت به ازای هر نویسه با استفاده از کدگذاری ISO-8859-1 / Latin-1 ذخیره و بازنمایی می‌شوند. این امر مقدار فضای مورد نیاز برای رشته‌هایی را که صرفاً حاوی نویسه‌های تک‌بایتی هستند، تا ۵۰٪ کاهش می‌دهد. برای رشته‌های جاوایی که حداقل حاوی یک نویسه چندبایتی هستند: این رشته‌ها با استفاده از کدگذاری UTF-16 به‌صورت ۲ بایت به ازای هر نویسه ذخیره و بازنمایی می‌شوند. غیرفعال کردن ویژگی Compact Strings، استفاده از کدگذاری UTF-16 را به‌عنوان بازنمایی داخلی برای تمام رشته‌های جاوا اجباری می‌کند.
مواردی که غیرفعال کردن Compact Strings در آن‌ها می‌تواند سودمند باشد شامل موارد زیر است:
  • زمانی که مشخص باشد برنامه به شکلی غالب اقدام به تخصیص رشته‌های حاوی نویسه‌های چندبایتی خواهد کرد
  • در رویداد غیرمنتظره‌ای که افتی در کارایی هنگام مهاجرت از Java SE 8 به Java SE 9 مشاهده شود و تحلیل‌ها نشان دهند که Compact Strings مسبب این افت کارایی است در هر دوی این سناریوها، غیرفعال کردن Compact Strings منطقی است.
مسیر و نام فایلی را مشخص می‌کند که در صورت وقوع یک خطای غیرقابل بازیابی، داده‌های خطا در آن نوشته می‌شوند. به‌طور پیش‌فرض، این فایل در دایرکتوری کاری جاری ایجاد شده و hs_err_pidpid.log نامیده می‌شود که در آن pid شناسه فرایندی است که با خطا مواجه شده است.
مثال زیر نحوه تنظیم فایل لاگ پیش‌فرض را نشان می‌دهد (توجه داشته باشید که شناسه فرایند به‌صورت %p مشخص می‌شود):

-XX:ErrorFile=./hs_err_pid%p.log

•
غیر ویندوز (Non-Windows): مثال زیر نحوه تنظیم گزارش خطا به /var/log/java/java_error.log را نشان می‌دهد:

-XX:ErrorFile=/var/log/java/java_error.log

•
ویندوز (Windows): مثال زیر نحوه تنظیم فایل گزارش خطا به C:/log/java/java_error.log را نشان می‌دهد:

-XX:ErrorFile=C:/log/java/java_error.log

اگر فایل از قبل موجود بوده و قابل نوشتن باشد، بازنویسی خواهد شد. در غیر این صورت، چنانچه فایل نتواند در دایرکتوری مشخص‌شده ایجاد شود (به دلیل کمبود فضا، مشکل دسترسی یا هر مسئله دیگری)، فایل در دایرکتوری موقت سیستم‌عامل ایجاد می‌شود:
  • غیر ویندوز (Non-Windows): دایرکتوری موقت /tmp است.
  • ویندوز (Windows): دایرکتوری موقت با مقدار متغیر محیطی TMP مشخص می‌شود؛ اگر آن متغیر محیطی تعریف نشده باشد، از مقدار متغیر محیطی TEMP استفاده خواهد شد.
گزارش‌دهی اطلاعات جامع‌تر و گسترده‌تر خطا را در ErrorFile فعال می‌کند. این گزینه می‌تواند در محیط‌هایی که حداکثر اطلاعات مورد نیاز است روشن شود - حتی اگر لاگ‌های حاصل بسیار حجیم باشند و/یا حاوی اطلاعاتی باشند که حساس تلقی شوند. این اطلاعات می‌تواند از نگارشی به نگارش دیگر و در بسترهای مختلف تفاوت داشته باشد. به‌طور پیش‌فرض این گزینه غیرفعال است.
پارامترهایی را که رفتار JFR را کنترل می‌کنند تنظیم می‌کند. می‌توان چندین پارامتر را با جدا کردن آن‌ها به‌وسیله ویرگول مشخص کرد.
فهرست زیر شامل ورودی‌های دردسترس parameter=value برای JFR است:
میزان کل حافظه اصلی مورد استفاده برای نگهداری داده‌ها را مشخص می‌کند. مقدار پیش‌فرض بر اساس مقدار مشخص‌شده برای memorysize تعیین می‌شود. برای تغییر دادن اندازه بافرهای سراسری، پارامتر memorysize را تغییر دهید.
حداکثر اندازه (به بایت) تکه‌های داده در یک ضبط (recording) را مشخص می‌کند. برای تعیین اندازه بر حسب مگابایت (MB)، حرف m یا M، و برای تعیین اندازه بر حسب گیگابایت (GB)، حرف g یا G را به انتها بیفزایید. به‌طور پیش‌فرض، حداکثر اندازه تکه‌های داده روی 12 MB تنظیم شده است. حداقل مقدار مجاز 1 MB است.
تعیین می‌کند چه مقدار حافظه بافر باید استفاده شود، و پارامترهای globalbuffersize و numglobalbuffers را بر اساس اندازه مشخص‌شده تنظیم می‌کند. برای تعیین اندازه بر حسب مگابایت (MB)، حرف m یا M، و برای تعیین اندازه بر حسب گیگابایت (GB)، حرف g یا G را به انتها بیفزایید. به‌طور پیش‌فرض، اندازه حافظه روی 10 MB تنظیم شده است.
تعداد بافرهای سراسری مورد استفاده را مشخص می‌کند. مقدار پیش‌فرض بر اساس اندازه حافظه مشخص‌شده تعیین می‌شود. برای تغییر تعداد بافرهای سراسری، پارامتر memorysize را تغییر دهید..TP old-object-queue-size=number-of-objects حداکثر تعداد اشیاء قدیمی برای ردیابی. به‌طور پیش‌فرض، تعداد اشیاء روی 256 تنظیم شده است.
مشخص می‌کند که آیا فایل‌های ذخیره‌شده در مخزن دیسک باید پس از خروج JVM نگهداری شوند یا خیر. اگر false باشد، فایل‌ها حذف می‌شوند. به‌طور پیش‌فرض، این پارامتر غیرفعال است.
مخزن (یک دایرکتوری) را برای ذخیره‌سازی موقت روی دیسک مشخص می‌کند. به‌طور پیش‌فرض، از دایرکتوری موقت سیستم استفاده می‌شود.
مشخص می‌کند که آیا کلاس‌های رویداد باید با استفاده از JVMTI بازدگرگون (retransform) شوند یا خیر. اگر false باشد، تجهیز (instrumentation) هنگام بارگذاری کلاس‌های رویداد اضافه می‌شود. به‌طور پیش‌فرض، این پارامتر فعال است.
عمق پشته برای ردگیری‌های پشته (stack traces). به‌طور پیش‌فرض، عمق روی ۶۴ فراخوانی متد تنظیم شده است. حداکثر مقدار ۲۰۴۸ است. مقادیر بزرگ‌تر از ۶۴ می‌توانند سربار قابل‌توجهی ایجاد کرده و کارایی را کاهش دهند.
اندازه بافر محلی به‌ازای هر نخ (به بایت) را مشخص می‌کند. به‌طور پیش‌فرض، اندازه بافر محلی روی ۸ کیلوبایت تنظیم شده و حداقل مقدار آن ۴ کیلوبایت است. بازنویسی این پارامتر می‌تواند کارایی را کاهش دهد و توصیه نمی‌شود.
حداکثر اندازه صفحه بزرگ (به بایت) مورد استفاده توسط JVM را تنظیم می‌کند. آرگومان size باید یک اندازه صفحه معتبر و پشتیبانی‌شده توسط محیط باشد تا تأثیر بگذارد. برای مشخص کردن کیلوبایت، حرف k یا K، برای مگابایت، m یا M، و برای گیگابایت، g یا G را ضمیمه کنید. به‌طور پیش‌فرض، اندازه روی 0 تنظیم شده است؛ بدین معنی که JVM از اندازه پیش‌فرض صفحه بزرگِ محیط به عنوان حداکثر اندازه برای صفحات بزرگ استفاده خواهد کرد. بخش Large Pages را ببینید.
مثال زیر نحوه تنظیم اندازه صفحه بزرگ روی ۱ گیگابایت (GB) را نشان می‌دهد:

-XX:LargePageSizeInBytes=1g

حداکثر اندازه کل (به بایت) تخصیص‌های بافر مستقیم (direct-buffer) در بسته java.nio را تنظیم می‌کند. برای مشخص کردن کیلوبایت، حرف k یا K، برای مگابایت، m یا M، و برای گیگابایت، g یا G را ضمیمه کنید. اگر تنظیم نشود، این پرچم نادیده گرفته شده و JVM اندازه تخصیص‌های بافر مستقیم NIO را به‌طور خودکار انتخاب می‌کند.
مثال‌های زیر نحوه تنظیم اندازه NIO به ۱۰۲۴ کیلوبایت در واحدهای مختلف را نشان می‌دهند: 
-XX:MaxDirectMemorySize=1m
-XX:MaxDirectMemorySize=1024k
-XX:MaxDirectMemorySize=1048576
تلاش برای تنظیم حد نرم (soft limit) تعداد توصیف‌کننده‌های فایل باز روی حد سخت (hard limit) را غیرفعال می‌کند. به‌طور پیش‌فرض، این گزینه در تمام پلتفرم‌ها فعال است، اما در Windows نادیده گرفته می‌شود. تنها زمانی که ممکن است نیاز به غیرفعال کردن آن داشته باشید در macOS است، جایی که استفاده از آن حداکثر مقدار ۱۰۲۴۰ را تحمیل می‌کند که کمتر از حداکثر واقعی سیستم است.
حالت ردیابی مصرف حافظه بومی (native memory) ماشین مجازی جاوا (JVM) را مشخص می‌کند. آرگومان‌های ممکنِ mode برای این گزینه شامل موارد زیر است:
دستور می‌دهد که مصرف حافظه بومی JVM ردیابی نشود. اگر گزینه -XX:NativeMemoryTracking را مشخص نکنید، این رفتار پیش‌فرض است.
مصرف حافظه را فقط بر اساس زیرسیستم‌های JVM نظیر Java heap، کلاس، کد و نخ (thread) ردیابی می‌کند.
علاوه بر ردیابی مصرف حافظه توسط زیرسیستم‌های JVM، مصرف حافظه را بر اساس هر CallSite مجزا، ناحیه حافظه مجازی مجزا و نواحی تخصیص‌یافته (committed) آن ردیابی می‌کند.
بازه زمانی، به میلی‌ثانیه، که در آن JVM هیپ بومی (native heap) را هرس (trim) می‌کند. مقادیر کمتر، حافظه را مشتاقانه‌تر بازپس‌گیری می‌کنند اما هزینه آن سربار بالاتر است. مقدار 0 (پیش‌فرض) هرس هیپ بومی را غیرفعال می‌کند. هرس هیپ بومی در یک نخ اختصاصی انجام می‌شود.
این گزینه فقط روی Linux با کتابخانه سی گنو (glibc) پشتیبانی می‌شود.
هم‌ترازی حافظه اشیاء جاوا را (به بایت) تنظیم می‌کند. به‌طور پیش‌فرض، این مقدار روی ۸ بایت تنظیم شده است. مقدار مشخص‌شده باید توانی از ۲ باشد و حتماً در بازه ۸ تا ۲۵۶ (شامل هر دو) قرار گیرد. این گزینه استفاده از اشاره‌گرهای فشرده (compressed pointers) را با اندازه‌های بزرگ Java heap امکان‌پذیر می‌سازد.
محدودیت اندازه heap به بایت به صورت زیر محاسبه می‌شود:

4GB * ObjectAlignmentInBytes

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

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

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

•
Windows: مثال زیر نشان می‌دهد که چگونه می‌توان از گزینه -XX:OnError برای اجرای ابزار userdump.exe جهت دریافت رونوشت خرابی (crash dump) در صورت بروز خطای غیرقابل جبران استفاده کرد (%p شناسه فرایند فعلی را مشخص می‌کند). این مثال فرض می‌کند که مسیر ابزار userdump.exe در متغیر محیطی PATH مشخص شده است:

-XX:OnError="userdump.exe %p"

یک دستور سفارشی یا مجموعه‌ای از دستورهای جداشده با نقطه‌ویرگول را برای اجرا در زمانی که استثنای OutOfMemoryError برای نخستین بار توسط JVM پرتاب می‌شود، تنظیم می‌کند. اگر رشته شامل فاصله باشد، باید درون علامت نقل‌قول قرار گیرد. برای نمونه‌ای از رشته دستور، به توضیحات گزینه -XX:OnError مراجعه کنید. این گزینه فقط برای استثناهای OutOfMemoryError ناشی از اتمام Java Heap اعمال می‌شود؛ این مورد برای استثناهای OutOfMemoryError که مستقیماً از کد جاوا پرتاب می‌شوند و همچنین مواردی که توسط JVM به دلیل اتمام سایر منابع (مانند خطاهای ایجاد نخ بومی) رخ می‌دهند اعمال نخواهد شد..TP -XX:+PrintCommandLineFlags چاپ فلگ‌های انتخاب‌شده به‌صورت ارگونومیک توسط JVM را که در خط فرمان ظاهر شده‌اند، فعال می‌کند. دانستن مقادیر ارگونومیک تنظیم‌شده توسط JVM، مانند اندازه فضای heap و جمع‌آورنده زباله (garbage collector) انتخاب‌شده، می‌تواند مفید باشد. به‌طور پیش‌فرض، این گزینه غیرفعال است و فلگ‌ها چاپ نمی‌شوند.
بین استفاده از ثبات RBP به عنوان یک ثبات همه‌منظوره (-XX:-PreserveFramePointer) و استفاده از ثبات RBP برای نگه‌داری اشاره‌گر فریم (frame pointer) متد در حال اجرای فعلی (-XX:+PreserveFramePointer) انتخاب می‌کند. اگر اشاره‌گر فریم در دسترس باشد، ابزارهای خارجی ارزیابی کارایی (مانند Linux perf) می‌توانند ردپای پشته (stack trace) دقیق‌تری بسازند.
چاپ داده‌های جمع‌آوری‌شده ردیابی حافظه بومی (native memory tracking) را هنگام خروج JVM، در صورتی که ردیابی حافظه بومی فعال باشد (به -XX:NativeMemoryTracking مراجعه کنید)، فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و داده‌های ردیابی حافظه بومی چاپ نمی‌شوند.
مسیر و نام فایل آرشیو اشتراک‌گذاری داده‌های کلاس (CDS) را مشخص می‌کند.
به Application Class Data Sharing مراجعه کنید.
اگر این گزینه مشخص شود، JVM فایل آرشیو CDS را تنها در صورتی بارگذاری می‌کند که از بررسی یکپارچگی مبتنی بر چکسام‌های CRC32 با موفقیت عبور کند. هدف از این فلگ، بررسی آسیب‌های غیرعمدی واردشده به فایل‌های آرشیو CDS در حین انتقال یا ذخیره‌سازی است. برای تضمین امنیت و عملکرد صحیح CDS، کاربر باید اطمینان حاصل کند که فایل‌های آرشیو CDS مورد استفاده برنامه‌های جاوا نمی‌توانند بدون مجوز لازم تغییر یابند.
داده‌های اشتراکی اضافی افزوده‌شده به فایل آرشیو را مشخص می‌کند.
فایل متنی حاوی نام کلاس‌هایی را که باید در آرشیو اشتراک‌گذاری داده‌های کلاس (CDS) ذخیره شوند، مشخص می‌کند. این فایل شامل نام کامل یک کلاس در هر خط است، با این تفاوت که اسلش‌ها (/) جایگزین نقطه‌ها (.) می‌شوند. برای نمونه، جهت مشخص کردن کلاس‌های java.lang.Object و hello.Main، یک فایل متنی حاوی دو خط زیر ایجاد کنید:
java/lang/Object
hello/Main
کلاس‌هایی که در این فایل متنی مشخص می‌کنید باید شامل کلاس‌هایی باشند که به‌طور معمول توسط برنامه استفاده می‌شوند. آن‌ها می‌توانند شامل هر کلاسی از مسیرهای کلاس (class paths) برنامه، افزونه یا bootstrap باشند. به Application Class Data Sharing مراجعه کنید.
چاپ پیام‌های بهبودیافته NullPointerException را فعال می‌کند. هنگامی که یک برنامه خطای NullPointerException صادر می‌کند، این گزینه به JVM امکان می‌دهد دستورالعمل‌های بایت‌کد برنامه را تحلیل کند تا دقیقاً مشخص شود کدام ارجاع null است، و منبع را با یک پیام جزئیات مقدار تهی (null-detail) شرح دهد. پیام جزئیات مقدار تهی توسط NullPointerException.getMessage() محاسبه و بازگردانده می‌شود، و به عنوان پیام استثنا همراه با متد، نام فایل و شماره خط چاپ خواهد شد. به‌طور پیش‌فرض، این گزینه فعال است.
نمایش یک کادر محاوره‌ای را هنگام مواجهه JVM با یک خطای غیرقابل جبران فعال می‌کند. این امر مانع از خروج JVM می‌شود و فرایند را فعال نگه می‌دارد تا بتوانید یک اشکال‌زدا (debugger) به آن متصل کرده و علت خطا را بررسی کنید. به‌طور پیش‌فرض، این گزینه غیرفعال است.
یک ضبط JFR را برای برنامه جاوا آغاز می‌کند. این گزینه معادل دستور عیب‌یابی JFR.start است که ضبط را در زمان اجرا آغاز می‌کند. دستور -XX:StartFlightRecording:help گزینه‌های موجود و نمونه خطوط فرمان را چاپ می‌کند. هنگام آغاز ضبط JFR می‌توانید مقادیر parameter=value زیر را تنظیم کنید:
تأخیر بین زمان راه‌اندازی برنامه جاوا و شروع ضبط را مشخص می‌کند. پسوند s را برای تعیین زمان بر حسب ثانیه، m برای دقیقه، h برای ساعت، یا d برای روز اضافه کنید (برای نمونه، تعیین 10m به معنی ۱۰ دقیقه است). به‌طور پیش‌فرض، هیچ تأخیری وجود ندارد و این پارامتر روی 0 تنظیم شده است.
مشخص می‌کند که آیا داده‌ها حین ضبط روی دیسک نوشته شوند یا خیر. به‌طور پیش‌فرض، این پارامتر فعال است.
مشخص می‌کند که آیا ضبط در حال اجرا هنگام خاموش شدن JVM تخلیه (dump) شود یا خیر. در صورت فعال بودن و وارد نشدن filename، ضبط در فایلی در دایرکتوری محل آغاز فرایند نوشته می‌شود. نام فایل به‌صورت خودکار توسط سیستم تولید می‌شود و شامل شناسه فرایند (PID)، شناسه ضبط و برچسب زمانی فعلی است، شبیه به hotspot-pid-47496-id-1-2018_01_25_19_10_41.jfr. به‌طور پیش‌فرض، این پارامتر غیرفعال است.
مدت‌زمان ضبط را مشخص می‌کند. پسوند s را برای تعیین زمان بر حسب ثانیه، m برای دقیقه، h برای ساعت، یا d برای روز اضافه کنید (برای نمونه، تعیین 5h به معنی ۵ ساعت است). به‌طور پیش‌فرض، مدت‌زمان نامحدود است و این پارامتر روی 0 تنظیم شده است.
مسیر و نام فایلی را که هنگام توقف ضبط، داده‌ها در آن نوشته می‌شوند مشخص می‌کند؛ برای نمونه:
  • recording.jfr
  • /home/user/recordings/recording.jfr
  • c:\recordings\recording.jfr اگر %p و/یا %t در نام فایل مشخص شده باشد، به ترتیب به PID مربوط به JVM و برچسب زمانی فعلی بسط می‌یابد. نام فایل همچنین می‌تواند یک دایرکتوری باشد؛ در این حالت نام فایل بر اساس PID و تاریخ فعلی در دایرکتوری مشخص‌شده تولید می‌شود.
هم نام و هم شناسه یک ضبط را دریافت می‌کند.
حداکثر عمر داده‌های دیسک برای نگه‌داری در ضبط را مشخص می‌کند. این پارامتر تنها زمانی معتبر است که پارامتر disk روی true تنظیم شده باشد. پسوند s را برای تعیین زمان بر حسب ثانیه، m برای دقیقه، h برای ساعت، یا d را برای روز اضافه کنید (برای نمونه، تعیین 30s به معنی ۳۰ ثانیه است). به‌طور پیش‌فرض، حداکثر عمر نامحدود است و این پارامتر روی 0s تنظیم شده است.
حداکثر اندازه (بر حسب بایت) داده‌های دیسک برای نگه‌داری در ضبط را مشخص می‌کند. این پارامتر تنها زمانی معتبر است که پارامتر disk روی true تنظیم شده باشد. مقدار نباید کمتر از مقدار پارامتر maxchunksize باشد که با -XX:FlightRecorderOptions تنظیم شده است. پسوند m یا M را برای تعیین اندازه بر حسب مگابایت، یا g یا G را برای گیگابایت اضافه کنید. به‌طور پیش‌فرض، حداکثر اندازه داده‌های دیسک نامحدود است و این پارامتر روی 0 تنظیم شده است.
مشخص می‌کند که آیا مسیر به ریشه‌های جمع‌آوری زباله (GC roots) در پایان ضبط جمع‌آوری شود یا خیر. به‌طور پیش‌فرض، این پارامتر غیرفعال است.
مسیر به ریشه‌های GC برای یافتن نشت‌های حافظه (memory leaks) مفید است، اما جمع‌آوری آن زمان‌بر است. این گزینه را تنها زمانی فعال کنید که ضبط را برای برنامه‌ای آغاز می‌کنید که مشکوک به نشت حافظه است. اگر پارامتر settings روی profile تنظیم شده باشد، ردپای پشته (stack trace) مکانی که شیء بالقوه دارای نشت در آن تخصیص یافته بود، در اطلاعات جمع‌آوری‌شده گنجانده می‌شود.
نام نمایی (view) را که باید هنگام خاموش شدن ماشین مجازی جاوا (JVM) نمایش داده شود، مشخص می‌کند. برای مشخص کردن بیش از یک نما، از پارامتر report-on-exit به‌طور مکرر استفاده کنید. اگر گزینه disk روی false تنظیم شده باشد، این گزینه در دسترس نیست. برای مشاهده فهرست نماهای موجود، به jfr help view مراجعه کنید. به‌طور پیش‌فرض، هیچ گزارشی تولید نمی‌شود..TP settings=path مسیر و نام فایل تنظیمات رویداد (از نوع JFC) را مشخص می‌کند. به‌طور پیش‌فرض، فایل default.jfc که در JAVA_HOME/lib/jfr قرار دارد استفاده می‌شود. این فایل تنظیمات پیش‌فرض، مجموعه‌ای از پیش‌تعریف‌شده از اطلاعات را با سربار اندک جمع‌آوری می‌کند، بنابراین حداقل تأثیر را بر کارایی دارد و می‌توان از آن برای ضبط‌هایی که به‌طور پیوسته اجرا می‌شوند استفاده کرد.
فایل تنظیمات دومی نیز ارائه شده است، یعنی profile.jfc، که داده‌های بیشتری را نسبت به پیکربندی پیش‌فرض فراهم می‌کند، اما ممکن است سربار بیشتری داشته باشد و بر کارایی تأثیر بگذارد. زمانی که به اطلاعات بیشتری نیاز است، از این پیکربندی برای دوره‌های زمانی کوتاه استفاده کنید.
می‌توانید مقادیر چندین پارامتر را با جدا کردن آن‌ها با ویرگول مشخص کنید. تنظیمات رویداد و گزینه‌های .jfc را می‌توان با استفاده از نحو زیر مشخص کرد:
مقدار گزینه‌ای که باید تغییر کند را مشخص می‌کند. برای فهرست کردن گزینه‌های موجود، از ابزار JAVA_HOME/bin/jfr استفاده کنید.
مقدار تنظیم رویداد را برای تغییر مشخص می‌کند. از این قالب استفاده کنید: <event-name>#<setting-name>=<value>. برای افزودن یک تنظیم رویداد جدید، یک '+' به ابتدای نام رویداد اضافه کنید. می‌توانید با جدا کردن با ویرگول، مقادیر چندین تنظیم رویداد و گزینه .jfc را مشخص کنید. در صورت بروز تداخل بین یک پارامتر و یک گزینه .jfc، پارامتر اولویت خواهد داشت. جداکننده فاصله خالی را می‌توان برای مقادیر بازه زمانی حذف کرد، مانند 20ms. برای اطلاعات بیشتر درباره نحو تنظیمات، به Javadoc بسته jdk.jfr مراجعه کنید. برای اینکه در حین راه‌اندازی فقط هشدارها و خطاهای JFR را مشاهده کنید، -Xlog:jfr+startup=warning را تنظیم نمایید.
اندازه پشته ریسه (thread stack) جاوا را (به کیلوبایت) تنظیم می‌کند. استفاده از یک پسوند مقیاس، مانند k، منجر به مقیاس‌بندی مقدار کیلوبایت می‌شود، به‌طوری که -XX:ThreadStackSize=1k اندازه پشته ریسه جاوا را روی 1024*1024 بایت یا ۱ مگابایت تنظیم می‌کند. مقدار پیش‌فرض به بستر بستگی دارد. به عنوان مثال:
  • Linux/x64: 1024 KB
  • Linux/Aarch64: 2048 KB
  • macOS/x64: 1024 KB
  • macOS/Aarch64: 2048 KB
  • Windows: مقدار پیش‌فرض به حافظه مجازی بستگی دارد مثال‌های زیر نحوه تنظیم اندازه پشته ریسه را روی ۱ مگابایت در واحدهای مختلف نشان می‌دهند:
-XX:ThreadStackSize=1k
-XX:ThreadStackSize=1024
این گزینه مشابه با -Xss است.
هدرهای فشرده اشیاء (compact object headers) را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است. فعال‌سازی این گزینه ردپای حافظه در هیپ (heap) جاوا را (به‌طور میانگین) ۴ بایت به ازای هر شیء کاهش داده و اغلب کارایی را بهبود می‌بخشد.
این ویژگی در حین ادامه ارزیابی‌ها همچنان به‌طور پیش‌فرض غیرفعال خواهد ماند. انتظار می‌رود در نسخه‌های آتی به‌طور پیش‌فرض فعال شود و در نهایت تنها حالت عملیاتی خواهد بود.
استفاده از اشاره‌گرهای فشرده (compressed pointers) را غیرفعال می‌کند. به‌طور پیش‌فرض، این گزینه فعال است و از اشاره‌گرهای فشرده استفاده می‌شود. این کار به‌طور خودکار حداکثر اندازه هیپ ارگونومیک جاوا را به حداکثر مقدار حافظه‌ای که می‌تواند توسط اشاره‌گرهای فشرده پوشش داده شود محدود می‌کند. به‌طور پیش‌فرض این محدوده ۳۲ گیگابایت است.
با فعال بودن compressed oops، ارجاعات اشیاء به‌جای اشاره‌گرهای ۶۴ بیتی به‌صورت آفست‌های ۳۲ بیتی نمایش داده می‌شوند که معمولاً هنگام اجرای برنامه با اندازه‌های هیپ جاوا کوچکتر از محدوده اشاره‌گر compressed oops، کارایی را افزایش می‌دهد. این گزینه فقط برای JVMهای ۶۴ بیتی کار می‌کند. امکان استفاده از اشاره‌گرهای فشرده با اندازه‌های هیپ جاوا بزرگتر از ۳۲ گیگابایت نیز وجود دارد. گزینه -XX:ObjectAlignmentInBytes را ببینید.
فقط لینوکس: اکنون VM پشتیبانی خودکار از تشخیص کانتینر را فراهم می‌کند، که به ماشین مجازی اجازه می‌دهد مقدار حافظه و تعداد پردازنده‌های در دسترس یک فرآیند جاوا که در کانتینرهای docker اجرا می‌شود را تعیین کند. از این اطلاعات برای تخصیص منابع سیستم استفاده می‌شود. مقدار پیش‌فرض این پرچم true است و پشتیبانی از کانتینر به‌طور پیش‌فرض فعال است. می‌توان آن را با -XX:-UseContainerSupport غیرفعال کرد.
قابلیت Unified Logging برای کمک به عیب‌یابی مسائل مربوط به این پشتیبانی در دسترس است. برای حداکثر ثبت رویدادها از اطلاعات کانتینر، از -Xlog:os+container=trace استفاده کنید. برای توضیحات مربوط به استفاده از Unified Logging، بخش Enable Logging with the JVM Unified Logging Framework را ببینید.
استفاده از حافظه با صفحات بزرگ (large page memory) را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و از حافظه با صفحات بزرگ استفاده نمی‌شود.
بخش Large Pages را ببینید.
فقط لینوکس: استفاده از صفحات بزرگی را که می‌توانند به‌طور پویا رشد کنند یا کوچک شوند فعال می‌کند. این گزینه به‌طور پیش‌فرض غیرفعال است. ممکن است با transparent huge pages دچار مشکلات کارایی شوید، زیرا سیستم‌عامل صفحات دیگر را برای ایجاد صفحات بزرگ جابه‌جا می‌کند؛ این گزینه برای اهداف آزمایشی در دسترس قرار گرفته است.
غیر ویندوز: امکان نصب گرداننده‌های سیگنال (signal handlers) را توسط برنامه فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و برنامه اجازه نصب گرداننده‌های سیگنال را ندارد.
به کاربر اجازه می‌دهد گزینه‌های VM را در یک فایل مشخص کند، به عنوان مثال: java -XX:VMOptionsFile=/var/my_vm_options HelloWorld.
فقط لینوکس AArch64: حالت حفاظت از انشعاب (branch protection) را مشخص می‌کند. همه گزینه‌ها به جز none نیازمند این هستند که VM با فعال بودن حفاظت از انشعاب کامپایل شده باشد. علاوه بر این، برای حفاظت کامل، هرگونه کتابخانه محلی (native) ارائه‌شده توسط برنامه‌ها نیز باید با همان سطح از حفاظت کامپایل شده باشد.
آرگومان‌های mode ممکن برای این گزینه شامل موارد زیر است:
از حفاظت انشعاب استفاده نمی‌شود. این مقدار پیش‌فرض است.
تمام حالت‌های حفاظت انشعاب موجود در بستر جاری را فعال می‌کند.
حفاظت در برابر حملات مبتنی بر ROP را فعال می‌کند. (فقط AArch64 8.3+) این گزینه‌های java کامپایل پویای درجا (JIT) انجام‌شده توسط Java HotSpot VM را کنترل می‌کنند.
تعداد خطوطی که باید جلوتر از اشاره‌گر تخصیص نمونه پیش‌واکشی (prefetch) شوند را تنظیم می‌کند. به‌طور پیش‌فرض، تعداد خطوط پیش‌واکشی روی 1 تنظیم شده است:

-XX:AllocateInstancePrefetchLines=1

اندازه (به بایت) فاصله پیش‌واکشی را برای تخصیص شیء تنظیم می‌کند. حافظه‌ای که قرار است با مقدار اشیاء جدید نوشته شود، تا این فاصله با شروع از نشانی آخرین شیء تخصیص‌یافته پیش‌واکشی می‌شود. هر رشته (thread) جاوا نقطه تخصیص اختصاصی خود را دارد.
مقادیر منفی نشان می‌دهند که فاصله پیش‌واکشی بر اساس بستر (platform) انتخاب می‌شود. مقادیر مثبت تعداد بایت‌ها برای پیش‌واکشی هستند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، یا g یا G را برای گیگابایت اضافه کنید. مقدار پیش‌فرض روی -1 تنظیم شده است. مثال زیر نحوه تنظیم فاصله پیش‌واکشی به 1024 بایت را نشان می‌دهد:

-XX:AllocatePrefetchDistance=1024

دستورالعمل پیش‌واکشی را برای پیش‌واکشی جلوتر از اشاره‌گر تخصیص تنظیم می‌کند. مقادیر ممکن از 0 تا 3 هستند. دستورالعمل‌های واقعی مرتبط با این مقادیر به بستر (platform) بستگی دارد. به‌طور پیش‌فرض، دستورالعمل پیش‌واکشی روی 0 تنظیم شده است:

-XX:AllocatePrefetchInstr=0

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

-XX:AllocatePrefetchLines=5

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

-XX:AllocatePrefetchStepSize=16

سبک کد تولیدشده را برای دستورالعمل‌های پیش‌واکشی تعیین می‌کند. آرگومان style یک عدد صحیح از 0 تا 3 است:
0
دستورالعمل‌های پیش‌واکشی را تولید نکن.
1
دستورالعمل‌های پیش‌واکشی را پس از هر تخصیص اجرا کن. این تنظیم پیش‌فرض است.
2
برای تعیین زمان اجرای دستورالعمل‌های پیش‌واکشی، از اشاره‌گر واترمارکِ بلوک تخصیص محلی رشته (TLAB) استفاده کن.
3
برای هر خط حافظه موقت (cache line)، یک دستورالعمل پیش‌واکشی تولید کن.
کامپایل در پس‌زمینه را فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن کامپایل در پس‌زمینه، -XX:-BackgroundCompilation را مشخص کنید (این کار معادل تعیین -Xbatch است).
تعداد رشته‌های (threads) کامپایلر را برای استفاده در کامپایل تنظیم می‌کند. به‌طور پیش‌فرض، تعداد رشته‌های کامپایلر بسته به تعداد CPUها و حافظه در دسترس برای کد کامپایل‌شده، به‌صورت خودکار انتخاب می‌شود. مثال زیر نحوه تنظیم تعداد رشته‌ها به 2 را نشان می‌دهد:

-XX:CICompilerCount=2

ایجاد پویای رشته‌های کامپایلر تا سقف مشخص‌شده توسط -XX:CICompilerCount. این گزینه به‌طور پیش‌فرض فعال است.
یک command را برای اجرا روی یک method مشخص می‌کند. برای نمونه، جهت مستثنی کردن متد indexOf() از کلاس String از کامپایل شدن، از دستور زیر استفاده کنید:

-XX:CompileCommand=exclude,java/lang/String.indexOf

توجه داشته باشید که نام کامل کلاس مشخص می‌شود، شامل همه بسته‌ها و زیربسته‌ها که با اسلش (/) از هم جدا شده‌اند. برای سهولت در عملیات برش و چسباندن (cut-and-paste)، همچنین امکان استفاده از قالب نام متد تولیدشده توسط گزینه‌های -XX:+PrintCompilation و -XX:+LogCompilation وجود دارد:

-XX:CompileCommand=exclude,java.lang.String::indexOf

اگر متد بدون امضا (signature) مشخص شود، دستور روی همه متدهای دارای نام مشخص‌شده اعمال می‌شود. با این حال، می‌توانید امضای متد را نیز در قالب فایل کلاس مشخص کنید. در این حالت، باید آرگومان‌ها را درون علامت نقل‌قول قرار دهید؛ زیرا در غیر این صورت، پوسته (shell) با نقطه ویرگول به‌عنوان پایان دستور رفتار خواهد کرد. برای نمونه، اگر می‌خواهید فقط متد indexOf(String) از کلاس String از کامپایل شدن مستثنی شود، از عبارت زیر استفاده کنید:

-XX:CompileCommand="exclude,java/lang/String.indexOf,(Ljava/lang/String;)I"

همچنین می‌توانید از علامت ستاره (*) به عنوان نویسه عام (wildcard) برای نام‌های کلاس و متد استفاده کنید. برای نمونه، برای مستثنی کردن تمام متدهای indexOf() در همه کلاس‌ها از کامپایل شدن، از عبارت زیر استفاده کنید:

-XX:CompileCommand=exclude,*.indexOf

ویرگول‌ها و نقطه‌ها نام‌های مستعاری برای فاصله‌ها هستند که ارسال دستورات کامپایلر را از طریق پوسته آسان‌تر می‌کنند. می‌توانید با قرار دادن آرگومان درون علامت نقل‌قول، آرگومان‌ها را با استفاده از فاصله به عنوان جداکننده به -XX:CompileCommand ارسال کنید:

-XX:CompileCommand="exclude java/lang/String indexOf"

توجه داشته باشید که پس از تجزیه دستورات ارسال‌شده در خط فرمان با استفاده از گزینه‌های -XX:CompileCommand، کامپایلر JIT سپس دستورات را از فایل .hotspot_compiler می‌خواند. می‌توانید دستوراتی را به این فایل اضافه کنید یا با استفاده از گزینه -XX:CompileCommandFile فایل دیگری را مشخص کنید. برای افزودن چند دستور، یا گزینه -XX:CompileCommand را چندین بار مشخص کنید، یا هر آرگومان را با جداکننده خط جدید (\n) جدا نمایید. دستورهای زیر در دسترس هستند:
هنگام اشکال‌زدایی JVM یک نقطه توقف (breakpoint) تعیین می‌کند تا در آغاز کامپایل متد مشخص‌شده متوقف شود..TP compileonly تمام متدها را به جز متد مشخص‌شده از کامپایل مستثنی می‌کند. به عنوان یک جایگزین، می‌توانید از گزینهٔ -XX:CompileOnly استفاده کنید که امکان تعیین چندین متد را فراهم می‌سازد.
از درون‌خطی‌سازی (inlining) متد مشخص‌شده جلوگیری می‌کند.
متد مشخص‌شده را از کامپایل مستثنی می‌کند.
یک پیام راهنما برای گزینهٔ -XX:CompileCommand چاپ می‌کند.
تلاش می‌کند متد مشخص‌شده را درون‌خطی‌سازی کند.
ثبت وقایع کامپایل را (با گزینهٔ -XX:+LogCompilation) برای تمام متدها به جز متد مشخص‌شده مستثنی می‌کند. به‌طور پیش‌فرض، ثبت وقایع برای تمام متدهای کامپایل‌شده انجام می‌شود.
یک گزینهٔ کامپایل JIT را به جای آخرین آرگومان (option) به متد مشخص‌شده ارسال می‌کند. گزینهٔ کامپایل در انتها، پس از نام متد تنظیم می‌شود. برای نمونه، جهت فعال‌سازی گزینهٔ BlockLayoutByFrequency برای متد append() از کلاس StringBuffer، از دستور زیر استفاده کنید:

-XX:CompileCommand=option,java/lang/StringBuffer.append,BlockLayoutByFrequency

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

CompilerOracle: exclude java/lang/String.indexOf

می‌توانید با مشخص کردن گزینهٔ -XX:CompileCommand=quiet پیش از سایر گزینه‌های -XX:CompileCommand، جلوی این چاپ را بگیرید.
فایلی را تنظیم می‌کند که دستورهای کامپایلر JIT از آن خوانده می‌شوند. به‌طور پیش‌فرض، فایل .hotspot_compiler برای ذخیرهٔ دستورهای اجراشده توسط کامپایلر JIT استفاده می‌شود.
هر خط در فایل دستورها بیانگر یک دستور، نام یک کلاس، و نام یک متد است که دستور برای آن اعمال می‌شود. برای نمونه، این خط کد اسمبلی را برای متد toString() از کلاس String چاپ می‌کند:

print java/lang/String toString

اگر از دستورهایی برای اجرای کامپایلر JIT روی متدها استفاده می‌کنید، گزینهٔ -XX:CompileCommand را ببینید.
هنگام شروع برنامه، رهنمودها (directives) را از یک فایل به پشتهٔ رهنمودها اضافه می‌کند. بخش Compiler Control را ببینید: [https://docs.oracle.com/en/java/javase/12/vm/compiler-control1.html#GUID-94AD8194-786A-4F19-BFFF-278F8E237F3A].
گزینهٔ -XX:CompilerDirectivesFile باید همراه با گزینهٔ -XX:UnlockDiagnosticVMOptions که گزینه‌های عیب‌یابی JVM را فعال می‌سازد، استفاده شود.
هنگام شروع برنامه یا هنگام افزوده‌شدن یک رهنمود جدید، پشتهٔ رهنمودها را چاپ می‌کند.
گزینهٔ -XX:+CompilerDirectivesPrint باید همراه با گزینهٔ -XX:UnlockDiagnosticVMOptions که گزینه‌های عیب‌یابی JVM را فعال می‌سازد، استفاده شود.
فهرستی از متدها (جداشده با کاما) را تعیین می‌کند که کامپایل باید به آن‌ها محدود شود. تنها متدهای مشخص‌شده کامپایل می‌شوند.
دستور -XX:CompileOnly=method1,method2,...,methodN یک نام مستعار برای دستور زیر است: 
-XX:CompileCommand=compileonly,method1
-XX:CompileCommand=compileonly,method2
...
-XX:CompileCommand=compileonly,methodN
کنترل یکپارچه‌ای را برای نخستین کامپایل فراهم می‌کند. این گزینه زمان نخستین کامپایل متدها را برای هر دو حالت لایه‌ای (tiered) و غیرلایه‌ای (nontiered) کنترل می‌کند. گزینهٔ CompileThresholdScaling مقداری با ممیز شناور بین 0 و Inf+ دارد و آستانه‌های متناظر با حالت عملیاتی کنونی (هم لایه‌ای و هم غیرلایه‌ای) را مقیاس‌بندی می‌کند. تنظیم CompileThresholdScaling روی مقداری کمتر از 1.0 منجر به کامپایل زودهنگام‌تر می‌شود، در حالی که مقادیر بزرگ‌تر از 1.0 کامپایل را به تعویق می‌اندازند. تنظیم CompileThresholdScaling روی 0 معادل غیرفعال کردن کامپایل است.
استفاده از تحلیل گریز (escape analysis) را فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن استفاده از تحلیل گریز، گزینهٔ -XX:-DoEscapeAnalysis را مشخص کنید.
اندازهٔ اولیهٔ حافظهٔ پنهان کد (code cache) را (بر حسب بایت) تعیین می‌کند. حرف k یا K را برای تعیین کیلوبایت، m یا M را برای تعیین مگابایت، یا g یا G را برای تعیین گیگابایت به انتها اضافه کنید. مقدار پیش‌فرض به پلتفرم بستگی دارد. اندازهٔ اولیهٔ حافظهٔ پنهان کد نباید کمتر از کمینهٔ اندازهٔ صفحهٔ حافظهٔ سیستم باشد. مثال زیر نحوهٔ تنظیم اندازهٔ اولیهٔ حافظهٔ پنهان کد را روی ۳۲ کیلوبایت نشان می‌دهد:

-XX:InitialCodeCacheSize=32k

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

-XX:InlineSmallCode=1000

ثبت وقایع فعالیت‌های کامپایل را در فایلی با نام hotspot.log در دایرکتوری کاری فعلی فعال می‌کند. می‌توانید با استفاده از گزینهٔ -XX:LogFile، مسیر و نام فایل لاگ متفاوتی را مشخص کنید.
به‌طور پیش‌فرض، این گزینه غیرفعال است و فعالیت‌های کامپایل ثبت نمی‌شوند. گزینهٔ -XX:+LogCompilation باید همراه با گزینهٔ -XX:UnlockDiagnosticVMOptions که گزینه‌های عیب‌یابی JVM را فعال می‌سازد، استفاده شود. می‌توانید خروجی عیب‌یابی مشروح (verbose) را با استفاده از گزینهٔ -XX:+PrintCompilation فعال کنید تا هر بار که متدی کامپایل می‌شود، پیامی در کنسول چاپ شود. -XX:FreqInlineSize=size حداکثر اندازهٔ بایت‌کد (به بایت) یک متد پرتکرار (hot method) را برای درون‌خطی‌سازی (inlining) تنظیم می‌کند. این پرچم تنها روی کامپایلر C2 اعمال می‌شود. برای مشخص کردن کیلوبایت حرف k یا K، برای مگابایت حرف m یا M، و برای گیگابایت حرف g یا G را به انتها اضافه کنید. مقدار پیش‌فرض به سکو (platform) بستگی دارد. در مثال زیر روی ۳۲۵ بایت تنظیم شده است:

-XX:FreqInlineSize=325

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

-XX:MaxInlineSize=35

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

-XX:MaxInlineSize=35

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

-XX:MaxTrivialSize=6

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

-XX:MaxTrivialSize=6

حداکثر تعداد گره‌های مورد استفاده در حین کامپایل یک تک‌متد را تنظیم می‌کند. به‌طور پیش‌فرض این مقدار به قابلیت‌های فعال‌شده بستگی دارد. در مثال زیر، حداکثر تعداد گره‌ها روی ۱۰۰٬۰۰۰ تنظیم شده است:

-XX:MaxNodeLimit=100000

اندازهٔ بخش کد حاوی کدهای غیرمتد (nonmethod code) را به بایت تنظیم می‌کند.
بخش کد غیرمتد شامل کدهایی مانند بافرهای کامپایلر و مفسر بایت‌کد است. این نوع کد برای همیشه در حافظهٔ نهان کد (code cache) باقی می‌ماند. این پرچم تنها در صورتی استفاده می‌شود که -XX:SegmentedCodeCache فعال باشد.
اندازهٔ بخش کد حاوی متدهای پروفایل‌نشده را به بایت تنظیم می‌کند. این پرچم تنها در صورتی استفاده می‌شود که -XX:SegmentedCodeCache فعال باشد.
بهینه‌سازی عملیات الحاق رشته‌های String را فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن بهینه‌سازی عملیات الحاق رشته‌های String، پرچم -XX:-OptimizeStringConcat را مشخص کنید.
چاپ کد اسمبلی متدهای بایت‌کدی و بومی (native) را با استفاده از کتابخانهٔ خارجی hsdis-<arch>.so یا .dll فعال می‌کند. برای ماشین مجازی ۶۴ بیتی در Windows، این کتابخانه hsdis-amd64.dll است. این گزینه امکان مشاهدهٔ کد تولیدشده را فراهم می‌سازد که می‌تواند به عیب‌یابی مسائل کارایی کمک کند.
به‌طور پیش‌فرض، این گزینه غیرفعال است و کد اسمبلی چاپ نمی‌شود. گزینهٔ -XX:+PrintAssembly باید همراه با گزینهٔ -XX:UnlockDiagnosticVMOptions (که گزینه‌های عیب‌یابی JVM را فعال می‌کند) استفاده شود.
اندازهٔ بخش کد حاوی متدهای پروفایل‌شده را به بایت تنظیم می‌کند. این پرچم تنها در صورتی استفاده می‌شود که -XX:SegmentedCodeCache فعال باشد.
خروجی عیب‌یابی مشروح را از JVM با چاپ یک پیام در کنسول در هر بار کامپایل شدن یک متد فعال می‌کند. این گزینه امکان می‌دهد ببینید کدام متدها واقعاً کامپایل می‌شوند. به‌طور پیش‌فرض، این گزینه غیرفعال است و خروجی عیب‌یابی چاپ نمی‌شود.
همچنین می‌توانید با استفاده از گزینهٔ -XX:+LogCompilation فعالیت کامپایل را در یک فایل ثبت کنید.
چاپ تصمیمات مربوط به درون‌خطی‌سازی را فعال می‌کند. این گزینه امکان می‌دهد ببینید کدام متدها در حال درون‌خطی شدن هستند.
به‌طور پیش‌فرض، این گزینه غیرفعال است و اطلاعات درون‌خطی‌سازی چاپ نمی‌شود. گزینهٔ -XX:+PrintInlining باید همراه با گزینهٔ -XX:+UnlockDiagnosticVMOptions (که گزینه‌های عیب‌یابی JVM را فعال می‌کند) استفاده شود.
حداکثر اندازهٔ حافظهٔ نهان کد (code cache) را به بایت برای کدهای کامپایل‌شده توسط JIT تنظیم می‌کند. برای مشخص کردن کیلوبایت حرف k یا K، برای مگابایت حرف m یا M، و برای گیگابایت حرف g یا G را به انتها اضافه کنید. حداکثر اندازهٔ پیش‌فرض حافظهٔ نهان کد ۲۴۰ مگابایت است؛ اگر کامپایل لایه‌ای (tiered compilation) را با گزینهٔ -XX:-TieredCompilation غیرفعال کنید، اندازهٔ پیش‌فرض ۴۸ مگابایت خواهد بود. این گزینه دارای محدودیت ۲ گیگابایت است؛ در غیر این صورت یک خطا ایجاد می‌شود. حداکثر اندازهٔ حافظهٔ نهان کد نباید از اندازهٔ اولیهٔ آن کمتر باشد؛ گزینهٔ -XX:InitialCodeCacheSize را ببینید.
بخش‌بندی حافظهٔ نهان کد را فعال می‌کند، که بدون آن، حافظهٔ نهان کد تنها شامل یک بخش بزرگ است. با استفاده از -XX:+SegmentedCodeCache، بخش‌های جداگانه‌ای برای کدهای غیرمتد، متدهای پروفایل‌شده، و متدهای پروفایل‌نشده در نظر گرفته می‌شود. اندازهٔ بخش‌ها در زمان اجرا تغییر نمی‌کند. مزایای آن شامل کنترل بهتر بر ردپای حافظه (memory footprint)، کاهش تکه‌تکه‌شدگی کد (fragmentation)، و بهبود رفتار iTLB (instruction translation lookaside buffer) پردازنده و حافظهٔ نهان دستورالعمل به دلیل بهبود محلی‌سازی (locality) است.
این قابلیت در صورتی که کامپایل لایه‌ای فعال باشد (-XX:+TieredCompilation) و اندازهٔ حافظهٔ نهان کد رزروشده (-XX:ReservedCodeCacheSize) حداقل ۲۴۰ مگابایت باشد، به‌طور پیش‌فرض فعال است.
پیمایش پشتهٔ (stack scanning) متدهای فعال را مجبور می‌کند تا زمانی که تنها درصد مشخص‌شده‌ای از حافظهٔ نهان کد آزاد است، کدهای بدون استفاده را به‌طور تهاجمی پاکسازی کند. مقدار پیش‌فرض ۱۰٪ است..TP -XX:-TieredCompilation استفاده از کامپایل چندلایه‌ای (tiered compilation) را غیرفعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است.
استفاده از مجموعه دستورالعمل‌های SSE از یک نسخه مشخص را فعال می‌کند. به‌طور پیش‌فرض روی بالاترین نسخه پشتیبانی‌شده موجود تنظیم می‌شود (فقط x86).
استفاده از مجموعه دستورالعمل‌های AVX از یک نسخه مشخص را فعال می‌کند. به‌طور پیش‌فرض روی بالاترین نسخه پشتیبانی‌شده موجود تنظیم می‌شود (فقط x86).
اینترینسیک‌های مبتنی بر سخت‌افزار AES را برای سخت‌افزارهایی که از آن پشتیبانی می‌کنند فعال می‌کند. این گزینه به‌طور پیش‌فرض روی سخت‌افزارهایی که دستورالعمل‌های لازم را دارند روشن است. گزینه -XX:+UseAES همراه با UseAESIntrinsics استفاده می‌شود. پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
اینترینسیک‌های AES را فعال می‌کند. مشخص کردن -XX:+UseAESIntrinsics معادل فعال‌سازی هم‌زمان -XX:+UseAES نیز می‌باشد. برای غیرفعال کردن اینترینسیک‌های سخت‌افزاری AES، عبارت -XX:-UseAES -XX:-UseAESIntrinsics را مشخص کنید. برای مثال، جهت فعال‌سازی AES سخت‌افزاری، از پرچم‌های زیر استفاده کنید:

-XX:+UseAES -XX:+UseAESIntrinsics

پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
مشابه با -XX:+UseAESIntrinsics، اینترینسیک‌های AES/CTR را فعال می‌کند.
استفاده از اینترینسیک‌های GHASH را کنترل می‌کند. به‌طور پیش‌فرض روی پلتفرم‌هایی که از دستورالعمل‌های مربوطه پشتیبانی می‌کنند فعال است. پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
اینترینسیک‌های ChaCha20 را فعال می‌کند. این گزینه به‌طور پیش‌فرض برای پلتفرم‌های پشتیبانی‌شده فعال است. برای غیرفعال‌سازی اینترینسیک‌های ChaCha20، گزینه -XX:-UseChaCha20Intrinsics را مشخص کنید. پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
اینترینسیک‌های Poly1305 را فعال می‌کند. این گزینه به‌طور پیش‌فرض برای پلتفرم‌های پشتیبانی‌شده فعال است. برای غیرفعال‌سازی اینترینسیک‌های Poly1305، گزینه -XX:-UsePoly1305Intrinsics را مشخص کنید. پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
استفاده از روال‌های شتاب‌یافته رمزگذاری BASE64 را برای java.util.Base64 کنترل می‌کند. به‌طور پیش‌فرض روی پلتفرم‌هایی که از آن پشتیبانی می‌کنند فعال است. پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
استفاده از اینترینسیک الگوریتم چکسام Adler32 را برای java.util.zip.Adler32 کنترل می‌کند. به‌طور پیش‌فرض روی پلتفرم‌هایی که از آن پشتیبانی می‌کنند فعال است. پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
استفاده از اینترینسیک‌های CRC32 را برای java.util.zip.CRC32 کنترل می‌کند. به‌طور پیش‌فرض روی پلتفرم‌هایی که از آن پشتیبانی می‌کنند فعال است. پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
استفاده از اینترینسیک‌های CRC32C را برای java.util.zip.CRC32C کنترل می‌کند. به‌طور پیش‌فرض روی پلتفرم‌هایی که از آن پشتیبانی می‌کنند فعال است. پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
اینترینسیک‌های مبتنی بر سخت‌افزار را برای توابع درهم‌سازی رمزنگاری SHA در برخی سخت‌افزارها فعال می‌کند. گزینه UseSHA همراه با گزینه‌های UseSHA1Intrinsics، UseSHA256Intrinsics و UseSHA512Intrinsics استفاده می‌شود.
پرچم‌های UseSHA و UseSHA*Intrinsics به‌طور پیش‌فرض روی دستگاه‌هایی که از دستورالعمل‌های متناظر پشتیبانی می‌کنند فعال هستند. این ویژگی تنها هنگام استفاده از ارائه‌دهنده sun.security.provider.Sun برای عملیات‌های SHA قابل اجرا است. پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند. جهت غیرفعال‌سازی تمامی اینترینسیک‌های مبتنی بر سخت‌افزار SHA، گزینه -XX:-UseSHA را مشخص کنید. برای غیرفعال کردن تنها یک اینترینسیک خاص SHA، از گزینه متناظر مناسب استفاده کنید. برای مثال: -XX:-UseSHA256Intrinsics.
اینترینسیک‌ها را برای تابع درهم‌سازی رمزنگاری SHA-1 فعال می‌کند. پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
اینترینسیک‌ها را برای توابع درهم‌سازی رمزنگاری SHA-224 و SHA-256 فعال می‌کند. پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
اینترینسیک‌ها را برای توابع درهم‌سازی رمزنگاری SHA-384 و SHA-512 فعال می‌کند. پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
تبدیل توابع مختلف java.lang.Math.*Exact() به اینترینسیک را فعال می‌کند. به‌طور پیش‌فرض فعال است. پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
تبدیل BigInteger.multiplyToLen() به اینترینسیک را فعال می‌کند. به‌طور پیش‌فرض روی پلتفرم‌هایی که از آن پشتیبانی می‌کنند فعال است. پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
تبدیل BigInteger.squareToLen() به اینترینسیک را فعال می‌کند. به‌طور پیش‌فرض روی پلتفرم‌هایی که از آن پشتیبانی می‌کنند فعال است. پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
تبدیل BigInteger.mulAdd() به اینترینسیک را فعال می‌کند. به‌طور پیش‌فرض روی پلتفرم‌هایی که از آن پشتیبانی می‌کنند فعال است. پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
تبدیل BigInteger.montgomeryMultiply() به اینترینسیک را فعال می‌کند. به‌طور پیش‌فرض روی پلتفرم‌هایی که از آن پشتیبانی می‌کنند فعال است. پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
تبدیل BigInteger.montgomerySquare() به اینترینسیک را فعال می‌کند. به‌طور پیش‌فرض روی پلتفرم‌هایی که از آن پشتیبانی می‌کنند فعال است. پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
دستورالعمل‌های CMove (اسکالر و برداری) را صرف‌نظر از تحلیل سودآوری تولید می‌کند.
تخلیه حافظه پنهان کد (code cache) را پیش از خاموش شدن کامپایلر فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. جهت غیرفعال‌سازی تخلیه حافظه پنهان کد پیش از خاموش شدن کامپایلر، گزینه -XX:-UseCodeCacheFlushing را مشخص کنید.
بررسی این‌که آیا کارت پیش از به‌روزرسانی جدول کارت از قبل نشانه‌گذاری شده است یا خیر را فعال می‌کند. این گزینه به‌طور پیش‌فرض غیرفعال است. این گزینه تنها باید در دستگاه‌های چند سوکته استفاده شود، جایی که عملکرد برنامه‌های جاوای وابسته به عملیات‌های هم‌روند را بهبود می‌بخشد..TP -XX:+UseCountedLoopSafepoints نقاط امن (safepoint) را در حلقه‌های شمارشی (counted loops) نگه می‌دارد. مقدار پیش‌فرض آن به این بستگی دارد که آیا زباله‌روبِ انتخاب‌شده به نقاط امن با تاخیر کم نیاز دارد یا خیر.
تعداد تکرارها در حلقه داخلی strip mined را کنترل می‌کند. تکنیک Strip mining حلقه‌های شمارشی را به حلقه‌های تودرتوی دو سطحی تبدیل می‌کند. نقاط امن در حلقه بیرونی نگه داشته می‌شوند در حالی که حلقه درونی می‌تواند با حداکثر سرعت اجرا شود. این گزینه حداکثر تعداد تکرارها در حلقه درونی را کنترل می‌کند. مقدار پیش‌فرض ۱٬۰۰۰ است.
بهینه‌سازی strip mining حلقه را کنترل می‌کند. حلقه‌هایی با تعداد تکرار کمتر از مقدار مشخص‌شده، نقطه امنی در خود نخواهند داشت. مقدار پیش‌فرض ۱/۱۰ مقدار -XX:LoopStripMiningIter است.
توابع درونی (intrinsics) سخت‌افزاری FMA را برای سخت‌افزارهایی که دستورالعمل‌های FMA در آن‌ها در دسترس است (مانند Intel و ARM64) فعال می‌کند. توابع درونی FMA برای متدهای java.lang.Math.fma(a, b, c) تولید می‌شوند که مقدار عبارت‌های ( a * b + c ) را محاسبه می‌کنند.
تبدیل عملیات اسکالر (scalar) به عملیات superword را فعال می‌کند. روش Superword یک بهینه‌سازی برداری‌سازی (vectorization) است. این گزینه به صورت پیش‌فرض فعال است. برای غیرفعال کردن تبدیل عملیات اسکالر به عملیات superword، مقدار -XX:-UseSuperWord را مشخص کنید.

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

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

نکته: ابزارهایی مانند jcmd، jinfo، jmap و jstack که همراه با JDK عرضه می‌شوند، در صورت استفاده برای عیب‌یابی نسخه‌ای متفاوت از JDK پشتیبانی نمی‌شوند.

لینوکس و macOS: کاوشگرهای ابزار dtrace را برای تخصیص شیء فعال می‌کند.
لینوکس و macOS: کاوشگرهای ابزار dtrace را برای ورود به متد و خروج از متد فعال می‌کند.
لینوکس و macOS: کاوشگرهای ابزار dtrace را برای رویدادهای مانیتور (monitor events) فعال می‌کند.
تخلیه هیپ جاوا به یک فایل در دایرکتوری جاری با استفاده از نمایه‌ساز هیپ (HPROF) را در زمان پرتاب استثنای java.lang.OutOfMemoryError توسط JVM فعال می‌کند. می‌توانید مسیر و نام فایل تخلیه هیپ را با استفاده از گزینه -XX:HeapDumpPath به صورت صریح تعیین کنید. به طور پیش‌فرض، این گزینه غیرفعال است و هنگام پرتاب استثنای OutOfMemoryError هیپ تخلیه نمی‌شود. این ویژگی تنها برای استثناهای OutOfMemoryError ناشی از اتمام حافظه هیپ جاوا اعمال می‌شود؛ این گزینه برای استثناهای OutOfMemoryError که مستقیماً از کد جاوا پرتاب می‌شوند، یا توسط JVM برای سایر انواع اتمام منابع (مانند خطاهای ایجاد ریسه بومی) رخ می‌دهند، اعمال نخواهد شد.
مسیر و نام فایل را برای نوشتن تخلیه هیپ ارائه‌شده توسط نمایه‌ساز هیپ (HPROF) هنگام تنظیم بودن گزینه -XX:+HeapDumpOnOutOfMemoryError تعیین می‌کند. به طور پیش‌فرض، فایل در دایرکتوری کاری جاری ایجاد می‌شود و نام آن java_pid<pid>.hprof است که در آن <pid> شناسه فرایندی است که موجب بروز خطا شده است. مثال زیر نحوه تعیین صریح فایل پیش‌فرض را نشان می‌دهد (%p بیانگر شناسه فرایند فعلی است):

-XX:HeapDumpPath=./java_pid%p.hprof

•
غیر ویندوز: مثال زیر نحوه تنظیم فایل تخلیه هیپ روی /var/log/java/java_heapdump.hprof را نشان می‌دهد:

-XX:HeapDumpPath=/var/log/java/java_heapdump.hprof

•
ویندوز: مثال زیر نحوه تنظیم فایل تخلیه هیپ روی C:/log/java/java_heapdump.log را نشان می‌دهد:

-XX:HeapDumpPath=C:/log/java/java_heapdump.log

مسیر و نام فایل را برای محل نوشتن داده‌های گزارش وقایع (log) تعیین می‌کند. به طور پیش‌فرض، فایل در دایرکتوری کاری جاری ایجاد می‌شود و نام آن hotspot.log است.
•
غیر ویندوز: مثال زیر نحوه تنظیم فایل گزارش وقایع روی /var/log/java/hotspot.log را نشان می‌دهد:

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

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

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

چاپ بافت‌نگار (هیستوگرام) نمونه‌های کلاس را پس از یکی از رویدادهای زیر فعال می‌کند:
  • غیر ویندوز: Control+\ (SIGQUIT)
  • ویندوز: Control+C (SIGTERM) به طور پیش‌فرض، این گزینه غیرفعال است. تنظیم این گزینه معادل با اجرای دستور jmap -histo یا دستور jcmd pid GC.class_histogram است که در آن pid شناسه فرایند فعلی جاوا است.
چاپ قفل‌های java.util.concurrent را پس از یکی از رویدادهای زیر فعال می‌کند:
  • غیر ویندوز: Control+\ (SIGQUIT)
  • ویندوز: Control+C (SIGTERM) به طور پیش‌فرض، این گزینه غیرفعال است. تنظیم این گزینه معادل با اجرای دستور jstack -l یا دستور jcmd pid Thread.print -l است که در آن pid شناسه فرایند فعلی جاوا است.
محدوده مشخص‌شده را چاپ کرده و امکان آزمایش خودکار مقادیر را فراهم می‌سازد. بخش Validate Java Virtual Machine Flag Arguments را ببینید.
در صورت فعال بودن، داده‌های دودویی (binary) ابزار jstat را هنگام خروج برنامه جاوا ذخیره می‌کند. این داده‌های دودویی در فایلی با نام hsperfdata_pid ذخیره می‌شوند که در آن pid شناسه فرایند برنامه جاوای اجراشده توسط شما است. برای نمایش داده‌های کارایی موجود در این فایل، از دستور jstat به صورت زیر استفاده کنید:
jstat -class file:///path/hsperfdata_pid

jstat -gc file:///path/hsperfdata_pid

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

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

از VM درخواست می‌کند که پس از درخواست هر صفحه در هیپ جاوا از سیستم‌عامل و پیش از تحویل دادن حافظه به برنامه، آن صفحه را لمس (pre-touch) کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و همه صفحات هم‌زمان با استفاده برنامه از فضای هیپ، تخصیص قطعی می‌یابند.
تعداد رشته‌های مورداستفاده برای بازیافت حافظه هم‌روند را تنظیم می‌کند. مقدار threads را تقریباً روی ۱/۴ تعداد رشته‌های بازیافت حافظه موازی قرار می‌دهد. مقدار پیش‌فرض به تعداد پردازنده‌های (CPUs) در دسترس JVM بستگی دارد.
برای نمونه، جهت تنظیم تعداد رشته‌های GC هم‌روند روی ۲، گزینه زیر را مشخص کنید:

-XX:ConcGCThreads=2

گزینه‌ای را فعال می‌کند که پردازش فراخوانی‌های متد System.gc() را غیرفعال می‌سازد. این گزینه به‌طور پیش‌فرض غیرفعال است، به این معنی که فراخوانی‌های System.gc() پردازش می‌شوند. اگر پردازش فراخوانی‌های System.gc() غیرفعال باشد، JVM همچنان در صورت نیاز GC را اجرا خواهد کرد.
فراخوانی GC هم‌روند را با استفاده از درخواست System.gc() فعال می‌کند. این گزینه به‌طور پیش‌فرض غیرفعال است و تنها همراه با گزینه -XX:+UseG1GC می‌تواند فعال شود.
هنگامی که -XX:UseAdaptiveIHOP فعال باشد، این گزینه تعداد چرخه‌های نشانه‌گذاری تکمیل‌شده‌ای را که برای جمع‌آوری نمونه‌ها استفاده می‌شوند مشخص می‌کند، تا زمانی که G1 به‌صورت تطبیقی مقدار بهینه -XX:InitiatingHeapOccupancyPercent را تعیین کند. پیش از آن، G1 مستقیماً از مقدار -XX:InitiatingHeapOccupancyPercent برای این منظور استفاده می‌کند. مقدار پیش‌فرض ۳ است.
اندازه ناحیه‌هایی را تعیین می‌کند که در هنگام استفاده از بازیافت‌کننده G1 (Garbage-First)، هیپ جاوا به آن‌ها تقسیم می‌شود. این مقدار توانی از ۲ است و می‌تواند در بازه ۱ مگابایت تا ۳۲ مگابایت باشد. اندازه پیش‌فرض ناحیه به‌صورت ارگونومیک بر پایه اندازه هیپ و با هدف دستیابی به تقریباً ۲۰۴۸ ناحیه تعیین می‌شود.
مثال زیر اندازه زیربخش‌ها را روی ۱۶ مگابایت تنظیم می‌کند:

-XX:G1HeapRegionSize=16m

درصدی از هیپ را که مایل به هدررفت آن هستید تعیین می‌کند. Java HotSpot VM هنگامی که درصد قابل بازپس‌گیری کمتر از درصد هدررفت هیپ باشد، چرخه بازیافت حافظه ترکیبی (mixed) را آغاز نمی‌کند. مقدار پیش‌فرض ۵ درصد است.
درصدی از اندازه هیپ را برای استفاده به‌عنوان بیشینه اندازه نسل جوان (young generation) تعیین می‌کند. مقدار پیش‌فرض ۶۰ درصد از هیپ جاوای شما است.
این یک پرچم آزمایشی است. این تنظیم جایگزین تنظیم -XX:DefaultMaxNewGenPercent می‌شود.
تعداد هدف بازیافت‌های حافظه ترکیبی را پس از یک چرخه نشانه‌گذاری تنظیم می‌کند تا ناحیه‌های قدیمی با حداکثر داده زنده به میزان G1MixedGCLIveThresholdPercent جمع‌آوری شوند. مقدار پیش‌فرض ۸ بازیافت حافظه ترکیبی است. هدف بازیافت‌های ترکیبی این است که در محدوده این تعداد هدف باقی بمانند.
آستانه اشغال یک ناحیه قدیمی را جهت گنجانده شدن در یک چرخه بازیافت حافظه ترکیبی تعیین می‌کند. اشغال پیش‌فرض ۸۵ درصد است.
این یک پرچم آزمایشی است. این تنظیم جایگزین تنظیم -XX:G1OldCSetRegionLiveThresholdPercent می‌شود.
درصدی از هیپ را برای استفاده به‌عنوان کمینه اندازه نسل جوان تعیین می‌کند. مقدار پیش‌فرض ۵ درصد از هیپ جاوای شما است.
این یک پرچم آزمایشی است. این تنظیم جایگزین تنظیم -XX:DefaultMinNewGenPercent می‌شود.
حد بالایی را برای تعداد ناحیه‌های قدیمی قابل جمع‌آوری در طول یک چرخه بازیافت حافظه ترکیبی تعیین می‌کند. مقدار پیش‌فرض ۱۰ درصد از هیپ جاوا است.
درصدی از هیپ (۰ تا ۵۰) را که به‌عنوان یک سقف کاذب برای کاهش احتمال شکست ارتقا (promotion failure) در بازیافت‌کننده G1 رزرو می‌شود، تعیین می‌کند. هنگامی که این درصد را افزایش یا کاهش می‌دهید، مطمئن شوید که کل هیپ جاوا را به همان میزان تنظیم می‌کنید. به‌طور پیش‌فرض، این گزینه روی ۱۰٪ تنظیم شده است.
مثال زیر هیپ رزروشده را روی ۲۰٪ تنظیم می‌کند:

-XX:G1ReservePercent=20

محاسبه تطبیقی میزان اشغال نسل قدیمی را برای شروع کارهای پس‌زمینه جهت آماده‌سازی بازیافت نسل قدیمی کنترل می‌کند. در صورت فعال بودن، G1 برای چند بار نخست همان‌طور که با مقدار -XX:G1AdaptiveIHOPNumInitialSamples مشخص شده، از -XX:InitiatingHeapOccupancyPercent استفاده می‌کند، و پس از آن به‌طور خودکار مقدار بهینه جدیدی را برای اشغال اولیه به‌صورت تطبیقی محاسبه می‌نماید. در غیر این صورت، فرایند بازیافت نسل قدیمی همواره در میزان اشغال تعیین‌شده توسط -XX:InitiatingHeapOccupancyPercent آغاز می‌شود.
پیش‌فرض فعال است.
اندازه اولیه (به بایت) مخزن تخصیص حافظه را تنظیم می‌کند. این مقدار باید ۰ یا مضربی از ۱۰۲۴ و بزرگ‌تر از ۱ مگابایت باشد. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، یا g یا G را برای گیگابایت اضافه کنید. مقدار پیش‌فرض در زمان اجرا بر پایه پیکربندی سیستم انتخاب می‌شود.
مثال‌های زیر نحوه تنظیم اندازه حافظه تخصیص‌یافته به ۶ مگابایت را با استفاده از واحدهای مختلف نشان می‌دهند: 
-XX:InitialHeapSize=6291456
-XX:InitialHeapSize=6144k
-XX:InitialHeapSize=6m
اگر این گزینه را روی ۰ تنظیم کنید، اندازه اولیه برابر با مجموع اندازه‌های تخصیص‌یافته برای نسل قدیم و نسل جوان تعیین می‌شود. اندازه هیپ برای نسل جوان را می‌توان با استفاده از گزینه -XX:NewSize تنظیم کرد. توجه داشته باشید که گزینه -Xms هم کمینه و هم اندازه اولیه هیپ را تعیین می‌کند. اگر -Xms پس از -XX:InitialHeapSize در خط فرمان ظاهر شود، اندازه اولیه هیپ روی مقدار مشخص‌شده با -Xms تنظیم می‌شود. -XX:InitialRAMPercentage=percent مقدار اولیه حافظه‌ای را که JVM پیش از اعمال قواعد اکتشافی ارگونومی (ergonomics heuristics) برای هیپ جاوا استفاده خواهد کرد، بر حسب درصدی از حداکثر مقدار تعیین‌شده مطابق با گزینهٔ -XX:MaxRAM تنظیم می‌کند.
مثال زیر نحوه تنظیم درصد مقدار اولیه حافظه مورد استفاده برای هیپ جاوا را نشان می‌دهد:

-XX:InitialRAMPercentage=5

نسبت اولیه فضای survivor مورد استفاده توسط زباله‌روب توان عملیاتی (throughput garbage collector که با گزینهٔ -XX:+UseParallelGC فعال می‌شود) را تنظیم می‌کند. اندازه‌بندی تطبیقی (Adaptive sizing) به‌طور پیش‌فرض در زباله‌روب توان عملیاتی با استفاده از گزینهٔ -XX:+UseParallelGC فعال است، و اندازه فضای survivor متناسب با رفتار برنامه، با شروع از مقدار اولیه، تغییر می‌یابد. اگر اندازه‌بندی تطبیقی غیرفعال باشد (با استفاده از گزینهٔ -XX:-UseAdaptiveSizePolicy)، آنگاه باید از گزینهٔ -XX:SurvivorRatio برای تنظیم اندازه فضای survivor در کل مدت زمان اجرای برنامه استفاده شود.
فرمول زیر می‌تواند برای محاسبه اندازه اولیه فضای survivor (به اختصار S) بر اساس اندازه نسل جوان یا young generation (به اختصار Y) و نسبت اولیه فضای survivor (به اختصار R) استفاده شود:

S=Y/(R+2)

عدد ۲ در معادله نشان‌دهنده دو فضای survivor است. هرچه مقدار تعیین‌شده برای نسبت اولیه فضای survivor بزرگ‌تر باشد، اندازه اولیه فضای survivor کوچک‌تر خواهد بود. به‌طور پیش‌فرض، نسبت اولیه فضای survivor روی ۸ تنظیم شده است. اگر از مقدار پیش‌فرض برای اندازه فضای نسل جوان استفاده شود (۲ مگابایت)، اندازه اولیه فضای survivor برابر ۰٫۲ مگابایت خواهد بود. مثال زیر نحوه تنظیم نسبت اولیه فضای survivor روی ۴ را نشان می‌دهد:

-XX:InitialSurvivorRatio=4

درصد اشغال نسل قدیم یا old generation (بین ۰ تا ۱۰۰) را برای شروع چرخه‌های اولیه نشانه‌گذاری همگام (concurrent marking) در زباله‌روب G1 تنظیم می‌کند.
به‌طور پیش‌فرض، این مقدار آغازگر روی ۴۵٪ تنظیم شده است. مقدار ۰ به معنای چرخه‌های GC همگام و بی‌وقفه از همان ابتدا است تا زمانی که G1 این مقدار را به‌صورت تطبیقی تنظیم کند. همچنین گزینه‌های -XX:G1UseAdaptiveIHOP و -XX:G1AdaptiveIHOPNumInitialSamples را ببینید. مثال زیر نحوه تنظیم درصد اشغال آغازگر هیپ روی ۷۵٪ را نشان می‌دهد:

-XX:InitiatingHeapOccupancyPercent=75

یک هدف برای حداکثر زمان توقف GC (بر حسب میلی‌ثانیه) تعیین می‌کند. این یک هدف انعطاف‌پذیر (soft goal) است و JVM تمام تلاش خود را برای رسیدن به آن انجام خواهد داد. تنها G1 و Parallel از هدف حداکثر زمان توقف GC پشتیبانی می‌کنند. برای G1، مقدار پیش‌فرض هدف حداکثر زمان توقف ۲۰۰ میلی‌ثانیه است.
مثال زیر نحوه تنظیم حداکثر زمان هدف توقف به ۵۰۰ میلی‌ثانیه را نشان می‌دهد:

-XX:MaxGCPauseMillis=500

حداکثر اندازه (بر حسب بایت) مخزن تخصیص حافظه را تنظیم می‌کند. این مقدار باید مضربی از ۱۰۲۴ و بزرگ‌تر از ۲ مگابایت باشد. حرف k یا K را برای نشان دادن کیلوبایت، m یا M را برای نشان دادن مگابایت، یا g یا G را برای نشان دادن گیگابایت اضافه کنید. مقدار پیش‌فرض در زمان اجرا بر اساس پیکربندی سیستم انتخاب می‌شود. برای استقرارهای سرور، گزینه‌های -XX:InitialHeapSize و -XX:MaxHeapSize اغلب روی مقداری یکسان تنظیم می‌شوند.
مثال‌های زیر نحوه تنظیم حداکثر اندازه مجاز حافظه تخصیص‌یافته روی ۸۰ مگابایت را با استفاده از واحدهای مختلف نشان می‌دهند: 
-XX:MaxHeapSize=83886080
-XX:MaxHeapSize=81920k
-XX:MaxHeapSize=80m
گزینهٔ -XX:MaxHeapSize معادل -Xmx است.
حداکثر درصد مجاز فضای آزاد هیپ (۰ تا ۱۰۰) پس از یک رخداد GC را تعیین می‌کند. اگر فضای آزاد هیپ فراتر از این مقدار گسترش یابد، اندازه هیپ کوچک‌تر (shrink) می‌شود. به‌طور پیش‌فرض، این مقدار روی ۷۰٪ تنظیم شده است.
با کاهش مقادیر پارامترهای MaxHeapFreeRatio (مقدار پیش‌فرض ۷۰٪) و MinHeapFreeRatio (مقدار پیش‌فرض ۴۰٪) از طریق گزینه‌های خط فرمان -XX:MaxHeapFreeRatio و -XX:MinHeapFreeRatio، اندازه هیپ جاوا را به حداقل برسانید. کاهش MaxHeapFreeRatio تا مقدار کم ۱۰٪ و MinHeapFreeRatio تا ۵٪ با موفقیت اندازه هیپ را بدون افت عملکرد زیاد کاهش داده است؛ با این حال، نتایج ممکن است بسته به برنامه شما بسیار متفاوت باشد. مقادیر مختلف را برای این پارامترها امتحان کنید تا جایی که تا حد امکان کاهش یابند و در عین حال کارایی قابل قبولی را حفظ کنند.

-XX:MaxHeapFreeRatio=10 -XX:MinHeapFreeRatio=5

کاربرانی که سعی در کوچک نگه‌داشتن هیپ دارند، باید گزینهٔ -XX:-ShrinkHeapInSteps را نیز اضافه کنند. برای توضیحات مربوط به استفاده از این گزینه جهت کوچک نگه‌داشتن هیپ جاوا با کاهش ردپای پویا (dynamic footprint) برای برنامه‌های تعبیه‌شده (embedded)، به Performance Tuning Examples مراجعه کنید.
حداکثر میزان حافظه بومی (native memory) قابل تخصیص برای فراداده‌های کلاس (class metadata) را تنظیم می‌کند. به‌طور پیش‌فرض، این اندازه محدود نیست. میزان فراداده‌ها برای یک برنامه به خود برنامه، سایر برنامه‌های در حال اجرا و میزان حافظه در دسترس در سیستم بستگی دارد.
مثال زیر نحوه تنظیم حداکثر اندازه فراداده‌های کلاس روی ۲۵۶ مگابایت را نشان می‌دهد:

-XX:MaxMetaspaceSize=256m

حداکثر اندازه (بر حسب بایت) هیپ برای نسل جوان (nursery) را تعیین می‌کند. مقدار پیش‌فرض به‌صورت ارگونومیک (ergonomically) تنظیم می‌شود.
حداکثر میزان حافظه‌ای را که JVM می‌تواند پیش از اعمال قواعد اکتشافی ارگونومی برای هیپ جاوا استفاده کند، به صورت درصدی از حداکثر مقدار تعیین‌شده مطابق با گزینهٔ -XX:MaxRAM تنظیم می‌کند. مقدار پیش‌فرض ۲۵ درصد است.
مشخص کردن این گزینه در صورتی که نتیجه ترکیبی این گزینه و سایر گزینه‌های اثرگذار بر حداکثر میزان حافظه از محدوده حافظه آدرس‌پذیر توسط compressed oops بزرگ‌تر باشد، استفاده خودکار از compressed oops را غیرفعال می‌کند. برای اطلاعات بیشتر درباره compressed oops به -XX:UseCompressedOops مراجعه کنید. مثال زیر نحوه تنظیم درصد حداکثر میزان حافظه مورد استفاده برای هیپ جاوا را نشان می‌دهد:

-XX:MaxRAMPercentage=75

حداکثر میزان حافظه‌ای را که JVM می‌تواند پیش از اعمال قواعد اکتشافی ارگونومی برای هیپ جاوا در هیپ‌های کوچک (small heaps) استفاده کند، به صورت درصدی از حداکثر مقدار تعیین‌شده بر اساس گزینهٔ -XX:MaxRAM تنظیم می‌کند. یک هیپ کوچک، هیپی با اندازه تقریبی ۱۲۵ مگابایت است. مقدار پیش‌فرض ۵۰ درصد است.
مثال زیر نحوه تنظیم درصد حداکثر میزان حافظه مورد استفاده برای هیپ جاوا در هیپ‌های کوچک را نشان می‌دهد: -XX:MinRAMPercentage=75
حداکثر آستانه ارتقا (tenuring threshold) را برای استفاده در تعیین اندازه تطبیقی GC تنظیم می‌کند. بزرگ‌ترین مقدار 15 است. مقدار پیش‌فرض برای گردآورنده موازی (throughput) برابر با 15 است.
مثال زیر نحوه تنظیم حداکثر آستانه ارتقا روی 10 را نشان می‌دهد:

-XX:MaxTenuringThreshold=10

اندازه فضای تخصیص‌یافته فراداده‌های کلاس را تنظیم می‌کند که فراتر رفتن از آن برای نخستین بار، باعث اجرای بازیافت حافظه (garbage collection) می‌شود. این آستانه برای بازیافت حافظه، بسته به میزان فراداده‌های استفاده‌شده افزایش یا کاهش می‌یابد. اندازه پیش‌فرض به بستر بستگی دارد.
حداقل درصد مجاز فضای آزاد حافظه هیپ (0 تا 100) را پس از یک رخداد GC تعیین می‌کند. اگر فضای آزاد هیپ کمتر از این مقدار شود، هیپ گسترش می‌یابد. به‌طور پیش‌فرض، این مقدار روی 40% تنظیم شده است.
اندازه هیپ جاوا را با کاهش مقادیر پارامترهای MaxHeapFreeRatio (مقدار پیش‌فرض 70%) و MinHeapFreeRatio (مقدار پیش‌فرض 40%) با استفاده از گزینه‌های خط فرمان -XX:MaxHeapFreeRatio و -XX:MinHeapFreeRatio به حداقل برسانید. کاهش MaxHeapFreeRatio تا 10% و MinHeapFreeRatio تا 5% با موفقیت اندازه هیپ را بدون افت کارایی چشمگیر کاهش داده است؛ با این حال، نتایج ممکن است بسته به برنامه شما بسیار متفاوت باشد. مقادیر مختلفی را برای این پارامترها امتحان کنید تا جایی که تا حد امکان پایین بیایند و هم‌زمان کارایی قابل قبولی را حفظ کنند.

-XX:MaxHeapFreeRatio=10 -XX:MinHeapFreeRatio=5

کاربرانی که می‌خواهند اندازه هیپ را کوچک نگه دارند باید گزینه -XX:-ShrinkHeapInSteps را نیز اضافه کنند. برای شرح نحوه استفاده از این گزینه جهت کوچک نگه داشتن هیپ جاوا با کاهش ردپای پویای حافظه برای برنامه‌های تعبیه‌شده (embedded)، به بخش Performance Tuning Examples مراجعه کنید.
حداقل اندازه (به بایت) استخر تخصیص حافظه را تنظیم می‌کند. این مقدار باید 0، یا مضربی از 1024 و بزرگ‌تر از 1 مگابایت باشد. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، یا g یا G را برای گیگابایت الحاق کنید. مقدار پیش‌فرض در زمان اجرا بر اساس پیکربندی سیستم انتخاب می‌شود.
مثال‌های زیر نحوه تنظیم حداقل اندازه حافظه تخصیص‌یافته به 6 مگابایت را با استفاده از واحدهای مختلف نشان می‌دهند: 
-XX:MinHeapSize=6291456
-XX:MinHeapSize=6144k
-XX:MinHeapSize=6m
اگر این گزینه را روی 0 تنظیم کنید، حداقل اندازه برابر با مقدار اندازه اولیه در نظر گرفته می‌شود.
نسبت بین اندازه نسل جوان (young) و قدیم (old) را تنظیم می‌کند. به‌طور پیش‌فرض، این گزینه روی 2 تنظیم شده است. مثال زیر نحوه تنظیم نسبت نسل جوان به قدیم را روی 1 نشان می‌دهد:

-XX:NewRatio=1

اندازه اولیه (به بایت) هیپ را برای نسل جوان (nursery) تعیین می‌کند. حرف k یا K را برای تعیین کیلوبایت، m یا M را برای مگابایت، یا g یا G را برای گیگابایت اضافه کنید.
ناحیه نسل جوان در هیپ برای اشیاء جدید استفاده می‌شود. عملیات GC در این ناحیه بیشتر از سایر نواحی انجام می‌گیرد. اگر اندازه نسل جوان بیش از حد کم باشد، تعداد زیادی minor GC انجام خواهد شد. اگر این اندازه بیش از حد زیاد باشد، فقط full GC انجام می‌شود که تکمیل آن می‌تواند زمان زیادی ببرد. توصیه می‌شود اندازه نسل جوان را بیش از 25% و کمتر از 50% از کل اندازه هیپ نگه دارید. مثال‌های زیر نحوه تنظیم اندازه اولیه نسل جوان را به 256 مگابایت با واحدهای مختلف نشان می‌دهند: 
-XX:NewSize=256m
-XX:NewSize=262144k
-XX:NewSize=268435456
گزینه -XX:NewSize معادل با -Xmn است.
تعداد رشته‌های کاری stop-the-world (STW) را تنظیم می‌کند. مقدار پیش‌فرض به تعداد CPUهای در دسترس برای JVM و گردآورنده زباله انتخاب‌شده بستگی دارد.
به‌عنوان مثال، برای تنظیم تعداد رشته‌ها برای G1 GC به 2، گزینه زیر را مشخص کنید:

-XX:ParallelGCThreads=2

چاپ اطلاعات مربوط به تعیین اندازه تطبیقی نسل‌ها را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است.
مدت زمانی (به میلی‌ثانیه) را که یک شیء با دسترسی‌پذیری ضعیف (softly reachable) پس از آخرین ارجاع در هیپ فعال نگه داشته می‌شود، تعیین می‌کند. مقدار پیش‌فرض یک ثانیه طول عمر به ازای هر مگابایت فضای آزاد در هیپ است. گزینه -XX:SoftRefLRUPolicyMSPerMB مقادیر صحیحی را می‌پذیرد که نشان‌دهنده میلی‌ثانیه به ازای هر یک مگابایت از اندازه فعلی هیپ (برای Java HotSpot Client VM) یا حداکثر اندازه ممکن هیپ (برای Java HotSpot Server VM) هستند. این تفاوت بدین معناست که Client VM تمایل دارد به جای گسترش هیپ، ارجاع‌های نرم (soft references) را پاک‌سازی کند، در حالی که Server VM تمایل دارد به جای پاک‌سازی ارجاع‌های نرم، هیپ را گسترش دهد. در حالت دوم، مقدار گزینه -Xmx تأثیر چشمگیری بر سرعت بازیافت ارجاع‌های نرم دارد.
مثال زیر نحوه تنظیم مقدار را روی 2.5 ثانیه نشان می‌دهد: -XX:SoftRefLRUPolicyMSPerMB=2500
هیپ جاوا را به‌صورت تدریجی تا اندازه هدف که با گزینه -XX:MaxHeapFreeRatio مشخص شده، کاهش می‌دهد. این گزینه به‌طور پیش‌فرض فعال است. در صورت غیرفعال بودن، به جای نیاز به چندین چرخه بازیافت حافظه، اندازه هیپ جاوا بلافاصله به اندازه هدف کاهش می‌یابد. اگر می‌خواهید اندازه هیپ جاوا را به حداقل برسانید، این گزینه را غیرفعال کنید. در صورت غیرفعال بودن این گزینه، به احتمال زیاد با افت کارایی مواجه خواهید شد.
برای شرح نحوه استفاده از گزینه MaxHeapFreeRatio جهت کوچک نگه داشتن هیپ جاوا با کاهش ردپای پویای حافظه برای برنامه‌های تعبیه‌شده، به Performance Tuning Examples مراجعه کنید.
اشیای String را که با رسیدن به سن مشخص‌شده نامزد حذف داده‌های تکراری (deduplication) می‌شوند، تعیین می‌کند. سن یک شیء، معیاری از تعداد دفعاتی است که از بازیافت حافظه جان سالم به در برده است. گاهی از این فرایند با عنوان ارتقا (tenuring) یاد می‌شود.

نکته: اشیای String که پیش از رسیدن به این سن به ناحیه قدیمی هیپ ارتقا می‌یابند، همیشه نامزد deduplication در نظر گرفته می‌شوند. مقدار پیش‌فرض این گزینه 3 است. گزینه -XX:+UseStringDeduplication را ببینید.

نسبت بین اندازه فضای eden و اندازه فضای survivor را تعیین می‌کند. به‌طور پیش‌فرض، این گزینه روی 8 تنظیم شده است. مثال زیر نحوه تنظیم نسبت فضای eden/survivor روی 4 را نشان می‌دهد:
-XX:SurvivorRatio=4
درصد مورد نظر از فضای بازمانده (survivor space) را که پس از زباله‌روبی نسل جوان استفاده می‌شود (بین ۰ تا ۱۰۰)، تعیین می‌کند. به‌طور پیش‌فرض، این گزینه روی 50% تنظیم شده است.
مثال زیر نحوه تنظیم نسبت هدف فضای بازمانده روی 30% را نشان می‌دهد:

-XX:TargetSurvivorRatio=30

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

-XX:TLABSize=512k

استفاده از اندازه‌بندی تطبیقی نسل‌ها را فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن اندازه‌بندی تطبیقی نسل‌ها، -XX:-UseAdaptiveSizePolicy را مشخص کرده و اندازه استخر تخصیص حافظه را به‌طور صریح تنظیم کنید. گزینه -XX:SurvivorRatio را ببینید.
استفاده از زباله‌روب Garbage-First (G1) را فعال می‌کند. این یک زباله‌روب به سبک سرور است که برای ماشین‌های چندپردازنده‌ای با مقدار زیادی RAM طراحی شده است. این گزینه اهداف زمان مکث GC را با احتمال بالایی برآورده می‌کند، در حالی که توان عملیاتی مناسبی را نیز حفظ می‌نماید. زباله‌روب G1 برای برنامه‌هایی که نیاز به هیپ‌های بزرگ (اندازه‌های حدود 6 GB یا بزرگ‌تر) با نیازمندی‌های تأخیر محدود GC (زمان مکث پایدار و قابل پیش‌بینی زیر 0.5 ثانیه) دارند، پیشنهاد می‌شود. به‌طور پیش‌فرض، این گزینه فعال است و G1 به عنوان زباله‌روب پیش‌فرض استفاده می‌شود.
استفاده از سیاستی را فعال می‌کند که نسبت زمان صرف‌شده توسط JVM برای GC را پیش از پرتاب استثنای OutOfMemoryError محدود می‌سازد. این گزینه به‌طور پیش‌فرض فعال است، و اگر بیش از 98% از کل زمان صرف زباله‌روبی شود و کمتر از 2% از هیپ بازیابی گردد، GC موازی یک OutOfMemoryError پرتاب خواهد کرد. هنگامی که هیپ کوچک است، می‌توان از این ویژگی برای جلوگیری از اجرای طولانی‌مدت برنامه‌ها با پیشرفت کم یا بدون پیشرفت استفاده کرد. برای غیرفعال کردن این گزینه، گزینه -XX:-UseGCOverheadLimit را مشخص کنید.
بهینه‌سازی کارایی برنامه را در ماشینی با معماری حافظه غیریکنواخت (NUMA) از طریق افزایش استفاده برنامه از حافظه با تأخیر کمتر فعال می‌کند. مقدار پیش‌فرض این گزینه به زباله‌روب بستگی دارد.
استفاده از زباله‌روب موازی پاک‌سازی (Parallel Scavenge، که با نام زباله‌روب توان عملیاتی نیز شناخته می‌شود) را برای بهبود کارایی برنامه شما از طریق بهره‌گیری از چندین پردازنده فعال می‌کند.
به‌طور پیش‌فرض، این گزینه غیرفعال است و از زباله‌روب پیش‌فرض استفاده می‌شود.
استفاده از زباله‌روب سریالی (Serial GC) را فعال می‌کند. این گزینه عموماً بهترین انتخاب برای برنامه‌های کوچک و ساده‌ای است که به هیچ قابلیت خاصی از زباله‌روبی نیاز ندارند. به‌طور پیش‌فرض، این گزینه غیرفعال است و از زباله‌روب پیش‌فرض استفاده می‌شود.
حذف موارد تکراری رشته‌ها (String deduplication) را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است. برای استفاده از این گزینه، باید زباله‌روب Garbage-First (G1) را فعال کنید.
حذف موارد تکراری رشته‌ها با بهره‌گیری از این واقعیت که بسیاری از اشیاء String یکسان هستند، ردپای حافظه اشیاء String را روی هیپ جاوا کاهش می‌دهد. به جای اینکه هر شیء String به آرایه نویسه‌ای اختصاصی خود اشاره کند، اشیاء یکسان String می‌توانند به یک آرایه نویسه‌ای مشترک اشاره کنند.
استفاده از بلوک‌های تخصیص محلی نخ (TLAB) را در فضای نسل جوان فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن استفاده از TLABها، گزینه -XX:-UseTLAB را مشخص کنید.
استفاده از زباله‌روب Z (موسوم به ZGC) را فعال می‌کند. این یک زباله‌روب با تأخیر کم است که در ازای مقداری هزینه در توان عملیاتی، حداکثر زمان‌های مکث چند میلی‌ثانیه‌ای را ارائه می‌دهد. زمان‌های مکث مستقل از اندازه هیپ مورد استفاده هستند. از اندازه‌های هیپ از 8MB تا 16TB پشتیبانی می‌کند.
میزان تحمل جهش تخصیص (allocation spike tolerance) را برای ZGC تعیین می‌کند. به‌طور پیش‌فرض، این گزینه روی 2.0 تنظیم شده است. این ضریب، سطح جهش‌های تخصیص قابل انتظار را توصیف می‌کند. برای مثال، استفاده از ضریب 3.0 به این معنی است که می‌توان انتظار داشت نرخ تخصیص فعلی در هر زمان سه برابر شود.
حداکثر فاصله زمانی (به ثانیه) بین دو چرخه GC را هنگام استفاده از ZGC تعیین می‌کند. به‌طور پیش‌فرض، این گزینه روی 0 (غیرفعال) تنظیم شده است.
حداکثر قطعه‌قطعه شدن قابل قبول هیپ (به درصد) را برای ZGC تعیین می‌کند. به‌طور پیش‌فرض، این گزینه روی 25 تنظیم شده است. استفاده از مقدار کمتر باعث می‌شود هیپ با شدت بیشتری یکپارچه‌سازی (compact) شود تا به بهای مصرف زمان بیشتر CPU، حافظه بیشتری بازیابی گردد.
چرخه‌های پیش‌دستانه GC را هنگام استفاده از ZGC فعال می‌کند. به‌طور پیش‌فرض، این گزینه فعال است. اگر انتظار برود که اجرای یک چرخه GC کمترین تأثیر را بر برنامه در حال اجرا بگذارد، ZGC یک چرخه پیش‌دستانه GC را آغاز خواهد کرد. این گزینه زمانی مفید است که برنامه اغلب بیکار باشد یا اشیاء بسیار کمی را تخصیص دهد، اما همچنان بخواهید اندازه هیپ را پایین نگه دارید و اجازه دهید پردازش مرجع‌ها حتی در زمان وجود فضای خالی زیاد در هیپ، انجام شود.
لغو تخصیص (uncommit کردن) حافظه استفاده‌نشده هیپ را هنگام استفاده از ZGC فعال می‌کند. به‌طور پیش‌فرض، این گزینه فعال است. لغو تخصیص حافظه استفاده‌نشده هیپ، ردپای حافظه JVM را کاهش می‌دهد و آن حافظه را برای استفاده سایر فرآیندها در دسترس قرار می‌دهد.
مدت زمانی (به ثانیه) را تعیین می‌کند که حافظه هیپ باید پیش از لغو تخصیص، استفاده‌نشده باقی مانده باشد. به‌طور پیش‌فرض، این گزینه روی 300 (۵ دقیقه) تنظیم شده است. تخصیص (committing) و لغو تخصیص (uncommitting) حافظه، عملیات‌های نسبتاً پرهزینه‌ای هستند. استفاده از مقدار کمتر باعث می‌شود حافظه هیپ زودتر لغو تخصیص شود، که خطر نیاز به تخصیص مجدد و زودهنگام آن را به همراه دارد.
استفاده از زباله‌روب Shenandoah را فعال می‌کند. این یک زباله‌روب هم‌روند با زمان مکث کم است. زمان‌های مکث آن متناسب با اندازه هیپ نیستند. زباله‌روب Shenandoah می‌تواند با اشاره‌گرهای فشرده کار کند. برای اطلاعات بیشتر درباره اشاره‌گرهای فشرده، -XX:UseCompressedOops را ببینید.
حالت GC را برای استفاده Shenandoah GC تعیین می‌کند. به‌طور پیش‌فرض، این گزینه روی satb تنظیم شده است. این گزینه از جمله مشخص می‌کند چه موانعی (barriers) در حال استفاده هستند. مقادیر ممکن برای حالت شامل موارد زیر است:
زباله‌روب هم‌روند «عکس فوری در آغاز» (Snapshot-at-the-beginning) (سه گذر: علامت‌گذاری-انتقال-به‌روزرسانی یا mark-evac-update). این یک GC تک‌نسلی است.
این حالت نیز یک GC هم‌روند و «عکس فوری در آغاز» است، اما نسلی (generational) می‌باشد. لطفاً برای آگاهی از مزایا و خطرات آن، JEP 404 [https://openjdk.org/jeps/404] و JEP 521 [https://openjdk.org/jeps/521] را ببینید. -XX:ShenandoahGCHeuristics=heuristics روش‌های اکتشافی (heuristics) را برای استفاده توسط Shenandoah GC تنظیم می‌کند. به‌طور پیش‌فرض، این گزینه روی adaptive تنظیم شده است. این گزینه با انتخاب زمان آغاز GC، میزان پردازش در هر چرخه، و این‌که چه ویژگی‌های دیگری به‌طور خودکار فعال شوند، حالت GC انتخاب‌شده را بهینه‌سازی و تنظیم دقیق می‌کند. هنگامی که -XX:ShenandoahGCMode برابر با generational باشد، تنها گزینهٔ پشتیبانی‌شده همان حالت پیش‌فرض، یعنی adaptive است.
روش‌های اکتشافی ممکن عبارتند از:
برای حفظ مقدار مشخص‌شده‌ای از حافظه heap آزاد در تمام اوقات، حتی در حین چرخهٔ GC.
راه‌اندازی GC هنگامی که حافظه heap آزاد از یک آستانهٔ مشخص پایین‌تر برود.
اجرای مکررتر GC و با اهداف عمیق‌تر برای آزادسازی حافظه بیشتر.

این گزینه‌های java منسوخ شده‌اند و ممکن است در انتشار آیندهٔ JDK حذف شوند. آن‌ها هنوز پذیرفته شده و اعمال می‌شوند، اما هنگام استفاده از آن‌ها یک هشدار صادر می‌شود.

فایلی را تنظیم می‌کند که اطلاعات تفصیلی رویدادهای GC باید برای ثبت وقایع (لاگ‌گیری) به آن هدایت شوند. اگر هر دو گزینه با یک دستور java داده شوند، گزینهٔ -Xloggc بر -verbose:gc تقدم داشته و آن را بازنویسی می‌کند. -Xloggc:filename با -Xlog:gc:filename جایگزین شده است. بخش Enable Logging with the JVM Unified Logging Framework را ببینید.
مثال: -Xlog:gc:garbage-collection.log
استفاده از Java Flight Recorder (JFR) را در طول زمان اجرای برنامه فعال می‌کند. از نسخهٔ JDK 8u40 به بعد، استفاده از JFR دیگر نیازی به این گزینه ندارد.
پردازش موازی ارجاعات (reference processing) را فعال می‌کند. به‌طور پیش‌فرض، زباله‌روب‌هایی که از چندین نخ استفاده می‌کنند، در صورتی که تعداد نخ‌های موازی مورد استفاده بیشتر از یک باشد، پردازش ارجاعات را به‌صورت موازی انجام می‌دهند. این گزینه تنها زمانی در دسترس است که از زباله‌روب‌های throughput یا G1 استفاده شود (-XX:+UseParallelGC یا -XX:+UseG1GC). سایر زباله‌روب‌هایی که از چندین نخ بهره می‌برند، پردازش ارجاعات را همواره به‌صورت موازی انجام می‌دهند.
حداکثر مقدار حافظه‌ای را که JVM می‌تواند قبل از اعمال روش‌های اکتشافی ارگونومی برای Java heap استفاده کند، تنظیم می‌کند. مقدار پیش‌فرض، مقدار حافظهٔ در دسترس فرایند JVM است.
حداکثر مقدار حافظهٔ در دسترس فرایند JVM، کمینهٔ حافظهٔ فیزیکی دستگاه و هرگونه محدودیت تعیین‌شده توسط محیط (مانند container) است. مشخص کردن این گزینه در صورتی که نتیجهٔ ترکیبی این گزینه و سایر گزینه‌های مؤثر بر حداکثر مقدار حافظه، بزرگ‌تر از محدودهٔ حافظهٔ قابل آدرس‌دهی توسط compressed oops باشد، استفادهٔ خودکار از compressed oops را غیرفعال می‌کند. برای اطلاعات بیشتر دربارهٔ compressed oops گزینهٔ -XX:UseCompressedOops را ببینید. مثال زیر نحوهٔ تنظیم حداکثر مقدار حافظهٔ در دسترس را برای تعیین اندازهٔ Java heap روی ۲ گیگابایت نشان می‌دهد:

-XX:MaxRAM=2G

بهینه‌سازی Java heap را فعال می‌کند. این گزینه پارامترهای گوناگونی را بر اساس پیکربندی رایانه (RAM و CPU) به‌گونه‌ای تنظیم می‌کند که برای کارهای طولانی‌مدت با تخصیص شدید حافظه بهینه باشند. به‌طور پیش‌فرض، این گزینه غیرفعال است و اندازه‌های heap با تهاجم کمتری پیکربندی می‌شوند.
حالت "Client VM emulation" را فعال می‌کند که تنها از کامپایلر C1 JIT، یک CodeCache با اندازهٔ ۳۲ مگابایت و Serial GC استفاده می‌کند. حداکثر مقدار حافظه‌ای که JVM می‌تواند استفاده کند (کنترل‌شده توسط پرچم -XX:MaxRAM=n) به‌طور پیش‌فرض روی 1GB تنظیم می‌شود. رشتهٔ "emulated-client" به رشتهٔ نگارش JVM افزوده می‌شود.
این پرچم به‌طور پیش‌فرض تنها در Windows در حالت ۳۲ بیتی روی true و در تمام موارد دیگر روی false تنظیم شده است. در صورت استفاده از هر یک از پرچم‌های زیر در خط فرمان، حالت "Client VM emulation" فعال نخواهد شد: 
-XX:{+|-}TieredCompilation
-XX:CompilationMode=mode
-XX:TieredStopAtLevel=n
-XX:{+|-}EnableJVMCI
-XX:{+|-}UseJVMCICompiler
این گزینه‌های java همچنان پذیرفته می‌شوند اما نادیده گرفته خواهند شد، و در صورت استفاده از آن‌ها یک هشدار صادر می‌شود.
مفهوم کپسوله‌سازی قوی آسان‌گیرانه (relaxed strong encapsulation) را آن‌گونه که در JEP 261 [https://openjdk.org/jeps/261#Relaxed-strong-encapsulation] تعریف شده است، کنترل می‌کرد. این گزینه در JDK 16 توسط JEP 396 [https://openjdk.org/jeps/396] ناموصی (deprecated) اعلام شد و در JDK 17 توسط JEP 403 [https://openjdk.org/jeps/403] کاملاً منسوخ گردید.

هیچ گزینهٔ مستندشده‌ای از java در JDK 26 حذف نشده است.

برای مشاهدهٔ فهرست و توضیحات گزینه‌های حذف‌شده در نسخه‌های پیشین، بخش Removed Java Options را در منابع زیر ببینید:

شما می‌توانید با استفاده از فایل‌های آرگومان حاوی @ برای تعیین یک یا چند فایل متنی حاوی آرگومان‌ها (مانند گزینه‌ها و نام‌های کلاس) که به دستور java ارسال می‌شوند، دستور java را کوتاه یا ساده کنید. این قابلیت به شما امکان می‌دهد دستورهای java با هر طولی را در هر سیستم‌عاملی ایجاد کنید.

در خط فرمان، از پیشوند علامت اتساین (@) برای مشخص کردن یک فایل آرگومان حاوی گزینه‌ها و نام‌های کلاس java استفاده کنید. هنگامی که دستور java با فایلی مواجه می‌شود که با علامت اتساین (@) آغاز شده است، محتویات آن فایل را درست به همان صورت که در خط فرمان تعیین می‌شدند، به یک فهرست آرگومان بسط می‌دهد.

راه‌انداز java محتویات فایل آرگومان را تا زمانی که به گزینهٔ --disable-@files برسد بسط می‌دهد. شما می‌توانید از گزینهٔ --disable-@files در هر جایی از خط فرمان، از جمله درون یک فایل آرگومان، برای متوقف کردن بسط فایل‌های آرگومان @ استفاده کنید.

موارد زیر نحو فایل‌های آرگومان java را توصیف می‌کنند:

  • فایل آرگومان باید تنها شامل نویسه‌های ASCII یا نویسه‌هایی در کدگذاری پیش‌فرض سیستم باشد که با ASCII سازگارند، مانند UTF-8.
  • اندازهٔ فایل آرگومان نباید از MAXINT (۲٬۱۴۷٬۴۸۳٬۶۴۷) بایت تجاوز کند.
  • راه‌انداز، نویسه‌های عام (wildcards) موجود در یک فایل آرگومان را بسط نمی‌دهد. این بدان معناست که یک ستاره (*) همان‌طور که هست به VM آغازین تحویل داده می‌شود. برای مثال، *.java به صورت *.java باقی می‌ماند و بر خلاف آنچه در برخی پوسته‌های خط فرمان رخ می‌دهد، به Foo.java Bar.java ... بسط داده نمی‌شود.
  • از نویسه‌های فاصله (white space) یا خط جدید برای جداسازی آرگومان‌های گنجانده‌شده در فایل استفاده کنید.
  • فاصله شامل یک نویسهٔ فاصله، \t، \n، \r و \f است.

به عنوان مثال، می‌توان مسیری دارای فاصله داشت، مانند c:\Program Files، که می‌تواند هم به صورت "c:\\Program Files" یا، برای پرهیز از کاراکتر گریز، به صورت c:\Program" "Files مشخص شود.

  • هر گزینه‌ای که حاوی فاصله باشد، مانند جزئی از یک مسیر، باید به طور کامل با نویسه‌های نقل‌قول ('"') احاطه شود.
  • یک رشتهٔ درون نقل‌قول می‌تواند حاوی نویسه‌های \n، \r، \t و \f باشد. این نویسه‌ها به کدهای ASCII متناظر خود تبدیل می‌شوند.
  • اگر نام یک فایل حاوی فاصله‌های درونی است، کل نام فایل را درون علامت‌های نقل‌قول دوگانه (double quotation) قرار دهید.
  • نام‌های فایل در یک فایل آرگومان نسبت به دایرکتوری جاری در نظر گرفته می‌شوند، نه نسبت به محل قرارگیری فایل آرگومان.
  • از علامت هش # در فایل آرگومان برای مشخص کردن توضیحات (comments) استفاده کنید. تمام نویسه‌های بعد از # تا انتهای خط نادیده گرفته می‌شوند.
  • علامت‌های اتساین @ پیشوندی بیشتر برای گزینه‌های دارای پیشوند @ به عنوان کاراکتر گریز (escape) عمل می‌کنند (اولین @ حذف شده و باقی آرگومان‌ها به صورت لفظی به راه‌انداز تحویل داده می‌شوند).
  • خطوط را می‌توان با استفاده از نویسهٔ ادامه (\) در انتهای خط ادامه داد. دو خط با حذف فاصله‌های ابتدایی به یکدیگر متصل می‌شوند. برای جلوگیری از حذف فاصله‌های ابتدایی، می‌توان نویسهٔ ادامه (\) را در ستون اول قرار داد.
  • از آنجا که بک‌اسلش (\) یک نویسهٔ گریز است، یک نویسهٔ بک‌اسلش باید با یک نویسهٔ بک‌اسلش دیگر گریز داده شود.
  • نقل‌قول جزئی مجاز است و با پایان فایل (end-of-file) بسته می‌شود.
  • یک نقل‌قول باز در انتهای خط متوقف می‌شود مگر اینکه \ آخرین نویسه باشد، که در این صورت با حذف تمامی نویسه‌های فاصلهٔ ابتدایی به خط بعدی متصل می‌شود.
  • استفاده از علامت اتساین (@) برای تفسیر بازگشتی فایل‌ها پشتیبانی نمی‌شود..SS مثال نقل‌قول‌های باز یا ناتمام در یک فایل آرگومان در فایل آرگومان،
-cp "lib/
cool/
app/
jars

این مورد به این صورت تفسیر می‌شود:

-cp lib/cool/app/jars

برای خروجی دادن موارد زیر:

-cp c:\Program Files (x86)\Java\jre\lib\ext;c:\Program Files\Java\jre9\lib\ext

نویسه بک‌اسلش باید در فایل آرگومان به این صورت مشخص شود:

-cp "c:\\Program Files (x86)\\Java\\jre\\lib\\ext;c:\\Program Files\\Java\\jre9\\lib\\ext"

در فایل آرگومان،

-cp "/lib/cool app/jars:\
    /lib/another app/jars"

این مورد به این صورت تفسیر می‌شود:

-cp /lib/cool app/jars:/lib/another app/jars

در فایل آرگومان،

-cp "/lib/cool\
\app/jars"

این مورد به این صورت تفسیر می‌شود:

-cp /lib/cool app/jars

می‌توانید از یک فایل آرگومان تکی، مانند myargumentfile در مثال زیر، برای نگهداری تمام آرگومان‌های مورد نیاز java استفاده کنید:

java @myargumentfile

می‌توانید مسیرهای نسبی را در فایل‌های آرگومان بگنجانید؛ با این حال، این مسیرها نسبت به دایرکتوری کاری فعلی سنجیده می‌شوند و نه نسبت به مسیر خودِ فایل‌های آرگومان. در مثال زیر، path1/options و path2/options بیانگر فایل‌های آرگومان با مسیرهای مختلف هستند. هر مسیر نسبی که درون آن‌ها باشد، نسبت به دایرکتوری کاری فعلی سنجیده می‌شود و نه فایل‌های آرگومان:

java @path1/options @path2/classes

مواقعی وجود دارد که داشتن دید و شناخت نسبت به وضعیت فعلی هیپ کد JVM می‌تواند برای پاسخ به سوالاتی از قبیل موارد زیر مفید باشد:

  • چرا JIT خاموش شد و سپس بارها و بارها دوباره روشن شد؟
  • تمام فضای هیپ کد کجا مصرف شده است؟
  • چرا method sweeper به‌طور موثر عمل نمی‌کند؟

جهت ارائه این بینش، قابلیت تحلیل وضعیت هیپ کد پیاده‌سازی شده است که امکان تحلیل در لحظه (on-the-fly) هیپ کد را فراهم می‌کند. فرآیند تحلیل به دو بخش تقسیم می‌شود. بخش اول کل هیپ کد را بررسی کرده و تمام اطلاعاتی را که مفید یا مهم تلقی می‌شوند جمع‌آوری و تجمیع می‌کند. بخش دوم شامل چندین مرحله مستقل است که اطلاعات جمع‌آوری‌شده را با تأکید بر جنبه‌های مختلف داده‌ها چاپ می‌کند. جمع‌آوری داده‌ها و چاپ آن‌ها بر اساس درخواست ("on request") انجام می‌شود..SS "نحو (Syntax)" درخواست‌ها برای تحلیل بلادرنگ و آنی (real-time, on-the-fly) را می‌توان با دستور زیر صادر کرد:

jcmd pid Compiler.CodeHeap_Analytics [function] [granularity]

اگر صرفاً علاقه‌مندید بدانید پس از اجرای یک بار کاری نمونه (workload)، وضعیت code heap چگونه است، می‌توانید از این گزینه خط فرمان استفاده کنید:

-Xlog:codecache=Trace

برای مشاهده وضعیت code heap هنگام بروز شرایط "CodeCache full"، ماشین مجازی (VM) را با این گزینه خط فرمان راه‌اندازی کنید:

-Xlog:codecache=Debug

برای شرح مفصل قابلیت تحلیل وضعیت code heap، توابع پشتیبانی‌شده و گزینه‌های میزان جزئیات (granularity)، به CodeHeap State Analytics (OpenJDK) [https://bugs.openjdk.org/secure/attachment/75649/JVM_CodeHeap_StateAnalytics_V2.pdf] مراجعه کنید.

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

-Xlog[:[what][:[output][:[decorators][:output-options[,...]]]]]

-Xlog:directive

ترکیبی از برچسب‌ها (tags) و سطوح (levels) را در قالب tag1[+tag2...][*][=level][,...] مشخص می‌کند. مگر در حالتی که نویسه عمومی (*) مشخص شده باشد، تنها پیام‌های ثبتی تطبیق داده می‌شوند که دقیقاً دارای برچسب‌های مشخص‌شده باشند. به -Xlog Tags and Levels مراجعه کنید.
نوع خروجی را تعیین می‌کند. در صورت مشخص نکردن نوع output، مقدار پیش‌فرض stdout خواهد بود. به -Xlog Output مراجعه کنید.
خروجی را برای استفاده از یک مجموعه سفارشی از تزیین‌کننده‌ها (decorators) پیکربندی می‌کند. در صورت مشخص نکردن decorators، مقادیر پیش‌فرض uptime، level و tags خواهند بود. به Decorations مراجعه کنید.
گزینه‌های خروجی ثبت وقایع -Xlog را تعیین می‌کند.
یک گزینه سراسری یا زیردستور: help، disable، async

چارچوب ثبت وقایع یکپارچه ماشین مجازی جاوا (JVM)، یک سامانه مشترک ثبت وقایع را برای تمام مؤلفه‌های JVM فراهم می‌کند. ثبت وقایع GC برای JVM تغییر یافته است تا از چارچوب جدید ثبت وقایع استفاده کند. نگاشت پرچم‌های قدیمی GC به پیکربندی متناظر جدید Xlog در Convert GC Logging Flags to Xlog شرح داده شده است. علاوه بر این، ثبت وقایع زمان اجرا (runtime) نیز برای استفاده از چارچوب یکپارچه ثبت وقایع JVM تغییر یافته است. نگاشت پرچم‌های قدیمی ثبت وقایع زمان اجرا به پیکربندی متناظر جدید Xlog در Convert Runtime Logging Flags to Xlog شرح داده شده است.

موارد زیر یک مرجع سریع برای دستور -Xlog و نحو گزینه‌ها ارائه می‌دهد:

ثبت وقایع JVM را در سطح info فعال می‌کند.
نحو کاربرد -Xlog و برچسب‌ها، سطوح و decorators دردسترس را به همراه نمونه خطوط فرمان و توضیحات چاپ می‌کند.
تمام ثبت وقایع را خاموش می‌کند و تمام پیکربندی‌های چارچوب ثبت وقایع از جمله پیکربندی پیش‌فرض هشدارها و خطاها را پاک می‌کند.
چندین آرگومان را به ترتیبی که در خط فرمان ظاهر می‌شوند اعمال می‌کند. چندین آرگومان -Xlog برای یک خروجی یکسان، بر اساس ترتیب داده‌شده یکدیگر را بازنویسی (override) می‌کنند.
مؤلفه option به صورت زیر تنظیم می‌شود:

[tag-selection][:[output][:[decorators][:output-options]]]

حذف کردن tag-selection به‌طور پیش‌فرض مجموعه برچسب all و سطح info را تعیین می‌کند.

tag[+...] all

برچسب all یک فرابرچسب (meta tag) متشکل از تمامی مجموعه‌برچسب‌های دردسترس است. ستاره (*) در تعریف مجموعه‌برچسب، بیانگر تطبیق نویسه عمومی (wildcard) است. تطبیق با نویسه عمومی تمام مجموعه‌برچسب‌هایی را انتخاب می‌کند که دست‌کم شامل برچسب‌های مشخص‌شده باشند. بدون نویسه عمومی، تنها تطابق‌های دقیق از مجموعه‌برچسب‌های مشخص‌شده انتخاب می‌شوند. مؤلفه output-options عبارت است از:

filecount=file-count filesize=file size with optional K, M or G suffix foldmultilines=<true|false>

هنگامی که foldmultilines برابر با true باشد، رویداد ثبت وقایعی که از چندین خط تشکیل شده باشد، با جایگزین کردن نویسه‌های خط جدید با توالی '\' و 'n' در خروجی، در قالب یک خط تکی جمع خواهد شد. نویسه‌های تک بک‌اسلش موجود نیز با توالی دو بک‌اسلش جایگزین می‌شوند تا این تبدیل قابل بازگشت باشد. استفاده از این گزینه با کدگذاری‌های نویسه UTF-8 ایمن است، اما سایر کدگذاری‌ها ممکن است به درستی کار نکنند. برای نمونه، ممکن است توالی‌های چندبایتی در Shift JIS و BIG5 را به‌صورت نادرست تبدیل کند. هنگامی که تنها گزینهٔ -Xlog و هیچ چیز دیگری در خط فرمان مشخص نشده باشد، از پیکربندی پیش‌فرض استفاده می‌شود. پیکربندی پیش‌فرض، بدون توجه به اینکه پیام با چه برچسب‌هایی مرتبط است، تمامی پیام‌های دارای سطحی منطبق با warning یا error را ثبت می‌کند. پیکربندی پیش‌فرض معادل وارد کردن دستور زیر در خط فرمان است:

-Xlog:all=warning:stdout:uptime,level,tags

ثبت وقایع را می‌توان در زمان اجرا از طریق دستورهای تشخیصی (با استفاده از ابزار jcmd) نیز کنترل کرد. هر آنچه را که می‌توان در خط فرمان مشخص کرد، به‌صورت پویا با دستور VM.log نیز قابل تعیین است. از آنجا که دستورهای تشخیصی به‌طور خودکار در قالب MBeanها ارائه می‌شوند، می‌توانید از JMX برای تغییر پیکربندی ثبت وقایع در زمان اجرا استفاده کنید.

هر پیام ثبت وقایع، یک سطح و یک مجموعه برچسب مرتبط با خود دارد. سطح پیام بیانگر میزان جزئیات آن است، و مجموعه برچسب مشخص می‌کند که پیام شامل چه مواردی است یا با کدام مؤلفهٔ JVM ارتباط دارد (مانند gc، jit یا os). نگاشت پرچم‌های GC به پیکربندی Xlog در Convert GC Logging Flags to Xlog شرح داده شده است. نگاشت پرچم‌های قدیمی ثبت وقایع زمان اجرا به پیکربندی متناظر Xlog در Convert Runtime Logging Flags to Xlog شرح داده شده است.

سطوح ثبت وقایع موجود:

  • off
  • trace
  • debug
  • info
  • warning
  • error

برچسب‌های ثبت وقایع موجود:

به معنای واقعی کلمه ده‌ها برچسب ثبت وقایع وجود دارد که ترکیب‌های مناسب آن‌ها گستره‌ای از خروجی‌های ثبت وقایع را فعال خواهد کرد. مجموعهٔ کامل برچسب‌های ثبت وقایع موجود را می‌توان با استفاده از -Xlog:help مشاهده کرد. مشخص کردن all به جای یک ترکیب برچسب، با تمامی ترکیب‌های برچسب‌ها مطابقت خواهد داشت.

گزینهٔ -Xlog از انواع خروجی‌های زیر پشتیبانی می‌کند:

  • stdout --- خروجی را به stdout می‌فرستد
  • stderr --- خروجی را به stderr می‌فرستد
  • file=filename --- خروجی را به فایل(های) متنی می‌فرستد.

هنگام استفاده از file=filename، مشخص کردن %p، %t و/یا %hn در نام فایل به‌ترتیب به PID، برچسب زمانی راه‌اندازی و نام میزبان JVM بسط می‌یابد. همچنین می‌توانید فایل‌های متنی را برای مدیریت چرخش فایل بر اساس اندازهٔ فایل و تعداد فایل‌های نگه‌داری‌شده در چرخش پیکربندی کنید. برای نمونه، جهت چرخش فایل وقایع در هر 10 مگابایت و نگه‌داشتن 5 فایل در چرخش، گزینه‌های filesize=10M, filecount=5 را مشخص کنید. اندازهٔ هدف فایل‌ها تضمین نمی‌شود که دقیق باشد، بلکه تنها یک مقدار تقریبی است. فایل‌ها به‌طور پیش‌فرض با حداکثر 5 فایل چرخشی با اندازهٔ هدف 20 مگابایت چرخانده می‌شوند، مگر آن‌که خلاف آن پیکربندی شده باشد. مشخص کردن filecount=0 به این معنی است که فایل وقایع نباید چرخانده شود. در این حالت، احتمال رونویسی شدن فایل وقایع از پیش موجود وجود دارد.

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

ثبت تمامی وقایع به‌صورت ناهمگام.

در حالت ثبت وقایع ناهمگام، محل‌های ثبت وقایع تمامی پیام‌ها را در یک بافر میانی صف‌بندی می‌کنند و یک ریسهٔ مستقل مسئول تخلیهٔ آن‌ها در خروجی‌های متناظر است. بافر میانی دارای اندازهٔ محدود است. در صورت پر شدن بافر، پیامی که در حال صف‌بندی است یا دور انداخته می‌شود (async:drop)، یا ریسه‌های ثبت وقایع تا زمانی که ریسهٔ تخلیه به آن‌ها برسد متوقف می‌شوند (async:stall). اگر حالت خاصی انتخاب نشود، به‌طور پیش‌فرض async:drop انتخاب می‌شود. در حالت async:drop تضمین می‌شود که عملیات نوشتن مدخل‌های وقایع غیرمسدودکننده (non-blocking) باشد.

گزینهٔ -XX:AsyncLogBufferSize=N سهم حافظه بر حسب بایت را برای بافر میانی مشخص می‌کند. مقدار پیش‌فرض باید به اندازهٔ کافی بزرگ باشد تا پاسخگوی بیشتر موارد باشد. کاربران در صورت نیاز می‌توانند مقداری سفارشی تعیین کنند تا بین بار اضافی حافظه و دقت ثبت وقایع مصالحه برقرار کنند..SS تزیینات (Decorations) پیام‌های لاگ با اطلاعاتی درباره پیام تزیین می‌شوند. می‌توانید هر خروجی را برای استفاده از مجموعه‌ای سفارشی از تزیین‌کننده‌ها پیکربندی کنید. ترتیب خروجی همیشه همان ترتیبی است که در جدول فهرست شده است. می‌توانید تزییناتی را که قرار است استفاده شوند در زمان اجرا پیکربندی کنید. تزیینات به ابتدای پیام لاگ اضافه می‌شوند. برای مثال:

[6.567s][info][gc,old] Old collection complete

نادیده‌گرفتن decorators به‌طور پیش‌فرض از uptime، level و tags استفاده می‌کند. تزیین‌کننده none خاص است و برای غیرفعال کردن تمام تزیینات به کار می‌رود.

تزیین‌کننده‌های time (t)، utctime (utc)، uptime (u)، timemillis (tm)، uptimemillis (um)، timenanos (tn)، uptimenanos (un)، hostname (hn)، pid (p)، tid (ti)، level (l) و tags (tg) را می‌توان برای عدم استفاده از تزیین، روی none نیز تنظیم کرد.

تزیینات پیام‌های لاگ

تزیینات توضیحات
time یا t زمان و تاریخ جاری در قالب ISO-8601.
utctime یا utc ساعت هماهنگ جهانی (Universal Time Coordinated یا Coordinated Universal Time).
uptime یا u زمان سپری‌شده از شروع JVM به ثانیه و میلی‌ثانیه. برای مثال، 6.567s.
timemillis یا tm همان مقدار تولیدشده توسط System.currentTimeMillis().
uptimemillis یا um میلی‌ثانیه‌های سپری‌شده از زمان شروع JVM.
timenanos یا tn همان مقدار تولیدشده توسط System.nanoTime().
uptimenanos یا un نانوثانیه‌های سپری‌شده از زمان شروع JVM.
hostname یا hn نام میزبان (hostname).
pid یا p شناسه فرایند (PID).
tid یا ti شناسه نخ (Thread identifier).
level یا l سطح مرتبط با پیام لاگ.
tags یا tg مجموعه برچسب‌های مرتبط با پیام لاگ.
تبدیل پرچم‌های لاگ‌گیری GC به Xlog
نگاشت پرچم‌های قدیمی لاگ‌گیری GC به پیکربندی Xlog
tab( );
lw(22.4n) lw(16.5n) lw(31.2n).
پرچم قدیمی زباله‌روبی (GC) پیکربندی Xlog
توضیحات
T}
G1PrintHeapRegions -Xlog:gc+region=trace
کاربرد ندارد
T}
GCLogFileSize هیچ پیکربندی‌ای در دسترس نیست
چرخش لاگ توسط چارچوب مدیریت می‌شود.
T}
NumberOfGCLogFiles کاربرد ندارد
چرخش لاگ توسط چارچوب مدیریت می‌شود.
T}
PrintAdaptiveSizePolicy -Xlog:gc+ergo*=level
از یک level با مقدار debug برای بیش‌تر اطلاعات،
یا یک level با مقدار trace برای همهٔ آنچه که توسط
PrintAdaptiveSizePolicy لاگ می‌شد، استفاده کنید.
T}
PrintGC -Xlog:gc
کاربرد ندارد
T}
PrintGCApplicationConcurrentTime -Xlog:safepoint
توجه داشته باشید که PrintGCApplicationConcurrentTime و
PrintGCApplicationStoppedTime با یک برچسب مشترک لاگ می‌شوند و
در سیستم لاگ‌گیری جدید تفکیک نشده‌اند.
T}
PrintGCApplicationStoppedTime -Xlog:safepoint
توجه داشته باشید که PrintGCApplicationConcurrentTime و
PrintGCApplicationStoppedTime با یک برچسب مشترک لاگ می‌شوند و
در سامانه جدید لاگ‌گیری تفکیک نشده‌اند.
T}
PrintGCCause کاربرد ندارد
علت GC اکنون همیشه در لاگ ثبت می‌شود.
T}
PrintGCDateStamps کاربرد ندارد
برچسب‌های تاریخ توسط چارچوب ثبت می‌شوند.
T}
PrintGCDetails -Xlog:gc*
کاربرد ندارد
T}
PrintGCID کاربرد ندارد
شناسه GC اکنون همیشه لاگ می‌شود.
T}
PrintGCTaskTimeStamps -Xlog:gc+task*=debug
کاربرد ندارد
T}
PrintGCTimeStamps کاربرد ندارد
برچسب‌های زمانی توسط چارچوب ثبت می‌شوند.
T}
PrintHeapAtGC -Xlog:gc+heap=trace
کاربرد ندارد
T}
PrintReferenceGC -Xlog:gc+ref*=debug
توجه داشته باشید که در لاگ‌گیری قدیمی، PrintReferenceGC تنها در
صورتی تأثیر داشت که PrintGCDetails نیز فعال شده باشد.
T}
PrintStringDeduplicationStatistics `-Xlog:gc+stringdedup*=debug
` کاربرد ندارد
T}
PrintTenuringDistribution -Xlog:gc+age*=level
از یک level با مقدار debug برای مرتبط‌ترین اطلاعات،
یا یک level با مقدار trace برای تمام آنچه که توسط
PrintTenuringDistribution لاگ می‌شد، استفاده کنید.
T}
UseGCLogFileRotation کاربرد ندارد
آنچه که برای PrintTenuringDistribution لاگ می‌شد.
T}
این پرچم‌های قدیمی دیگر شناخته‌شده نیستند و در صورت استفادهٔ مستقیم موجب خطا خواهند شد.
به‌جای آن‌ها از معادل ثبت گزارش یکپارچه استفاده کنید.
نگاشت پرچم‌های ثبت گزارش زمان اجرا به پیکربندی Xlog
tab( );
lw(15.0n) lw(20.2n) lw(34.7n).
پرچم قدیمی زمان اجرا پیکربندی Xlog
توضیحات
T}
TraceExceptions -Xlog:exceptions=info
غیرقابل اعمال
T}
TraceClassLoading -Xlog:class+load=level
از level=info برای اطلاعات عادی، یا از
level=debug برای اطلاعات بیشتر استفاده کنید.
در نحو ثبت گزارش یکپارچه (Unified Logging)،‏ -verbose:class برابر با
-Xlog:class+load=info,class+unload=info است.
T}
TraceClassLoadingPreorder -Xlog:class+preorder=debug
غیرقابل اعمال
T}
TraceClassUnloading -Xlog:class+unload=level
از level=info برای اطلاعات عادی، یا از
level=trace برای اطلاعات بیشتر استفاده کنید.
در نحو ثبت گزارش یکپارچه (Unified Logging)،‏ -verbose:class برابر با
-Xlog:class+load=info,class+unload=info است.
T}
VerboseVerification -Xlog:verification=info
غیرقابل اعمال
T}
TraceClassPaths -Xlog:class+path=info
غیرقابل اعمال
T}
TraceClassResolution -Xlog:class+resolve=debug
غیرقابل اعمال
T}
TraceClassInitialization -Xlog:class+init=info
غیرقابل اعمال
T}
TraceLoaderConstraints -Xlog:class+loader+constraints=info
غیرقابل اعمال
T}
TraceClassLoaderData -Xlog:class+loader+data=level
از level=debug برای اطلاعات عادی یا از
level=trace برای اطلاعات بیشتر استفاده کنید.
T}
TraceSafepointCleanupTime -Xlog:safepoint+cleanup=info
غیرقابل اعمال
T}
TraceSafepoint -Xlog:safepoint=debug
غیرقابل اعمال
T}
TraceMonitorInflation -Xlog:monitorinflation=debug
غیرقابل اعمال
T}
TraceRedefineClasses -Xlog:redefine+class*=level
مقادیر level=info،‏ debug و trace
به ترتیب حجم بیشتری از اطلاعات را ارائه می‌دهند.
T}
موارد زیر مثال‌هایی از کاربرد -Xlog هستند.
-Xlog
همه پیام‌ها را با استفاده از سطح info همراه با تزیینات uptime، levels و
tags در stdout ثبت می‌کند.
این معادل استفاده از دستور زیر است:
-Xlog:all=info:stdout:uptime,levels,tags
-Xlog:gc
پیام‌های دارای برچسب gc را با استفاده از سطح info
در stdout ثبت می‌کند.
پیکربندی پیش‌فرض برای تمامی پیام‌های دیگر در سطح
warning همچنان برقرار است.
-Xlog:gc,safepoint
پیام‌هایی را که دارای یکی از برچسب‌های gc یا
safepoint هستند، هر دو با استفاده از سطح info و با تزیینات پیش‌فرض،
در stdout ثبت می‌کند.
پیام‌هایی که هم‌زمان دارای هر دو برچسب gc و safepoint
باشند ثبت نخواهند شد.
-Xlog:gc+ref=debug
پیام‌هایی را که هم‌زمان دارای هر دو برچسب gc و ref هستند،
با استفاده از سطح debug و با تزیینات پیش‌فرض در stdout ثبت می‌کند.
پیام‌هایی که فقط دارای یکی از این دو برچسب باشند ثبت نخواهند شد.
-Xlog:gc=debug:file=gc.txt:none
پیام‌های دارای برچسب gc را با استفاده از سطح
debug بدون هیچ‌گونه تزییناتی در فایلی به نام gc.txt
ثبت می‌کند.
پیکربندی پیش‌فرض برای تمامی پیام‌های دیگر در سطح
warning همچنان برقرار است.
-Xlog:gc=trace:file=gctrace.txt:uptimemillis,pid:filecount=5,filesize=1024
پیام‌های دارای برچسب gc را با استفاده از سطح
trace در یک مجموعه فایل چرخشی با ۵ فایل و اندازهٔ ۱
مگابایت با نام پایهٔ gctrace.txt ثبت کرده و از تزیینات
uptimemillis و pid استفاده می‌کند.
پیکربندی پیش‌فرض برای تمامی پیام‌های دیگر در سطح
warning همچنان برقرار است.
-Xlog:gc::uptime,tid
پیام‌های دارای برچسب gc را با استفاده از سطح پیش‌فرض
'info' در خروجی پیش‌فرض stdout ثبت کرده و از
تزیینات uptime و tid استفاده می‌کند.
پیکربندی پیش‌فرض برای تمامی پیام‌های دیگر در سطح
warning همچنان برقرار است.
-Xlog:gc*=info,safepoint*=off
پیام‌هایی را که دست‌کم دارای برچسب gc هستند با استفاده از
سطح info ثبت می‌کند، اما ثبت پیام‌های دارای برچسب
safepoint را غیرفعال می‌سازد.
پیام‌هایی که هم‌زمان دارای هر دو برچسب gc و safepoint
باشند ثبت نخواهند شد.
-Xlog:disable -Xlog:safepoint=trace:safepointtrace.txt
تمامی گزارش‌گیری‌ها، از جمله هشدارها و خطاها را غیرفعال کرده و سپس
پیام‌های دارای برچسب safepoint را با سطح trace در
فایل safepointtrace.txt فعال می‌کند.
پیکربندی پیش‌فرض اعمال نمی‌شود، زیرا خط فرمان
با -Xlog:disable آغاز شده است.
"مثال‌های پیچیده کاربرد -Xlog (Complex -Xlog Usage Examples)"
موارد زیر چند مثال پیچیده از به‌کارگیری گزینهٔ
-Xlog را شرح می‌دهد.
-Xlog:gc+class*=debug
پیام‌هایی را که دست‌کم دارای برچسب‌های gc و class
هستند با استفاده از سطح debug در stdout ثبت می‌کند.
پیکربندی پیش‌فرض برای تمامی پیام‌های دیگر در سطح
warning همچنان برقرار است.
-Xlog:gc+meta*=trace,class*=off:file=gcmetatrace.txt
پیام‌هایی را که دست‌کم دارای برچسب‌های gc و meta
هستند با استفاده از سطح trace در فایل
metatrace.txt ثبت می‌کند، اما ثبت همهٔ پیام‌های دارای برچسب
class را غیرفعال می‌سازد.
پیام‌هایی که دارای برچسب‌های gc، meta و
class باشند ثبت نمی‌شوند، زیرا class* بر روی خاموش (off) تنظیم شده است.
پیکربندی پیش‌فرض برای تمامی پیام‌های دیگر در سطح
warning، به استثنای مواردی که شامل
class هستند برقرار است.
-Xlog:gc+meta=trace
پیام‌هایی را که دقیقاً دارای برچسب‌های gc و meta
هستند با استفاده از سطح trace در stdout ثبت می‌کند.
پیکربندی پیش‌فرض برای تمامی پیام‌های دیگر در سطح
warning همچنان برقرار است.
-Xlog:gc+class+heap*=debug,meta*=warning,threads*=off
پیام‌هایی را که دست‌کم دارای برچسب‌های gc، class و
heap هستند با استفاده از سطح trace در
stdout ثبت می‌کند، اما فقط پیام‌های دارای برچسب meta را با آن
سطح ثبت می‌نماید.
پیکربندی پیش‌فرض برای تمامی پیام‌های دیگر در سطح
warning، به استثنای مواردی که شامل
threads هستند برقرار است..SH "اعتبارسنجی آرگومان‌های پرچم ماشین مجازی جاوا (VALIDATE JAVA VIRTUAL MACHINE FLAG ARGUMENTS)"
مقادیر ارائه‌شده به تمام پرچم‌های خط فرمان ماشین مجازی جاوا (JVM) جهت اعتبارسنجی ارزیابی می‌شوند و در صورتی که مقدار ورودی نامعتبر یا خارج از محدوده باشد، پیام خطای مناسبی نمایش داده می‌شود.
چه این مقادیر به‌صورت ارگونومیک (ergonomic)، در خط فرمان، توسط یک ابزار ورودی یا از طریق APIها (برای نمونه، کلاس‌های موجود در بستهٔ
java.lang.management) تعیین شده باشند، مقادیر ارائه‌شده برای تمامی پرچم‌های خط فرمان ماشین مجازی جاوا (JVM) اعتبارسنجی می‌شوند.
ارگونومی در «راهنمای تنظیم بازیافت حافظه ماشین مجازی هات‌اسپات ویرایش استاندارد پلتفرم جاوا» (Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide) شرح داده شده است.
محدوده و محدودیت‌ها چه هنگام مقداردهی تمام پرچم‌ها در زمان راه‌اندازی JVM و چه هنگام تغییر مقدار یک پرچم در حین اجرا (برای نمونه با استفاده از ابزار jcmd) اعتبارسنجی می‌شوند.
اگر مقداری بررسی محدوده یا قید را نقض کند، JVM متوقف شده و یک پیام خطای مناسب روی جریان خطا چاپ می‌شود.
برای نمونه، اگر یک پرچم بررسی محدوده یا قید را نقض کند، JVM با یک خطا خارج می‌شود:
java -XX:AllocatePrefetchStyle=5 -version
intx AllocatePrefetchStyle=5 is outside the allowed range [ 0 ... 3 ]
Improperly specified VM option 'AllocatePrefetchStyle=5'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
پرچم -XX:+PrintFlagsRanges محدودهٔ تمام پرچم‌ها را چاپ می‌کند.
این پرچم امکان آزمایش خودکار پرچم‌ها را بر اساس مقادیر مشخص‌شده در محدوده‌ها فراهم می‌سازد.
برای پرچم‌هایی که محدودهٔ معینی دارند، نوع، نام و محدودهٔ واقعی در خروجی چاپ می‌شود.
برای نمونه:
intx ThreadStackSize [ 0 ... 9007199254740987 ] {pd product}
برای پرچم‌هایی که محدودهٔ مشخصی ندارند، مقادیر در خروجی نمایش داده نمی‌شوند.
برای نمونه:
size_t NewSize [ ... ] {product}
این موضوع به شناسایی پرچم‌هایی که نیاز به پیاده‌سازی دارند کمک می‌کند.
چارچوب آزمایش خودکار می‌تواند از پرچم‌هایی که مقداری نداشته و پیاده‌سازی نشده‌اند، صرف‌نظر کند.
"صفحات بزرگ (LARGE PAGES)"
شما می‌توانید از صفحات بزرگ (large pages) که با عنوان huge pages نیز شناخته می‌شوند، به‌عنوان صفحات حافظه‌ای استفاده کنید که به‌طور قابل‌توجهی از اندازهٔ استاندارد صفحهٔ حافظه (که بسته به پردازنده و سیستم‌عامل متغیر است) بزرگ‌ترند.
صفحات بزرگ بافرهای ترجمهٔ آدرس پردازنده (Translation-Lookaside Buffers یا TLB) را بهینه‌سازی می‌کنند.
بافر ترجمهٔ آدرس (TLB) یک حافظهٔ پنهان برای ترجمهٔ صفحات است که آخرین ترجمه‌های آدرس‌های مجازی به فیزیکیِ استفاده‌شده را در خود نگه می‌دارد.
یک TLB منبع سیستمی کمیابی است.
رخ دادن یک TLB miss می‌تواند هزینه‌بر باشد زیرا پردازنده ناچار است جدول سلسله‌مراتبی صفحات را بخواند که ممکن است به چندین بار دسترسی به حافظه نیاز داشته باشد.
با استفاده از صفحات حافظه با اندازهٔ بزرگ‌تر، یک مدخل واحد در TLB می‌تواند محدودهٔ بزرگ‌تری از حافظه را پوشش دهد.
این امر موجب کاهش فشار بر روی TLB می‌شود و برنامه‌های با مصرف حافظهٔ بالا ممکن است کارایی و عملکرد بهتری پیدا کنند.
با این حال، استفاده از صفحات بزرگ می‌تواند تأثیر منفی بر عملکرد سیستم بگذارد.
برای نمونه، هنگامی که مقدار زیادی از حافظه توسط یک برنامه پین (قفل) می‌شود، ممکن است کمبود حافظهٔ معمولی ایجاد کند و منجر به صفحه‌بندی بیش از حد در برنامه‌های دیگر شده و کل سیستم را کُند سازد.
همچنین، سیستمی که برای مدتی طولانی روشن بوده است ممکن است دچار تکه‌تکه‌شدگی (fragmentation) بیش از حد شود که می‌تواند تخصیص حافظهٔ کافی با صفحات بزرگ را غیرممکن کند.
هنگامی که این وضعیت رخ می‌دهد، سیستم‌عامل یا JVM به استفاده از صفحات معمولی بازمی‌گردند.
لینوکس و ویندوز از صفحات بزرگ پشتیبانی می‌کنند..SS "پشتیبانی از صفحات بزرگ در لینوکس (Large Pages Support for Linux)"
لینوکس از نسخهٔ 2.6 از صفحات بزرگ پشتیبانی می‌کند.
برای بررسی اینکه آیا محیط شما از صفحات بزرگ پشتیبانی می‌کند یا خیر، دستور زیر را امتحان کنید:
# cat /proc/meminfo | grep Huge
HugePages_Total: 0
HugePages_Free: 0
...
Hugepagesize: 2048 kB
اگر خروجی شامل مواردی با پیشوند "Huge" باشد، سیستم شما از صفحات بزرگ پشتیبانی می‌کند.
این مقادیر ممکن است بسته به محیط متغیر باشند.
فیلد Hugepagesize اندازهٔ پیش‌فرض صفحات بزرگ را در محیط شما نشان می‌دهد و سایر فیلدها جزئیات مربوط به صفحات بزرگِ این اندازه را نمایش می‌دهند.
کرنل‌های جدیدتر از چندین اندازهٔ مختلف برای صفحات بزرگ پشتیبانی می‌کنند.
برای فهرست کردن اندازه‌های پشتیبانی‌شدهٔ صفحات، این دستور را اجرا کنید:
# ls /sys/kernel/mm/hugepages/
hugepages-1048576kB hugepages-2048kB
محیط بالا از صفحات بزرگ ۲ مگابایتی و ۱ گیگابایتی پشتیبانی می‌کند، اما باید پیکربندی شوند تا JVM بتواند از آن‌ها استفاده کند.
هنگام استفاده از صفحات بزرگ و فعال نکردن صفحات بزرگ شفاف (گزینهٔ -XX:+UseTransparentHugePages)، تعداد صفحات بزرگ باید از پیش تخصیص داده شود.
برای مثال، برای فعال‌سازی ۸ گیگابایت حافظه با پشتیبانی صفحات بزرگ ۲ مگابایتی، با کاربر root وارد شده و اجرا کنید:
# echo 4096 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
همواره توصیه می‌شود پس از درخواست، مقدار nr_hugepages را بررسی کنید تا مطمئن شوید کرنل توانسته است تعداد صفحات بزرگ درخواستی را تخصیص دهد.
نکته: مقادیر موجود در /proc و /sys پس از راه‌اندازی مجدد سیستم بازنشانی می‌شوند، بنابراین ممکن است بخواهید آن‌ها را در یک اسکریپت راه‌اندازی اولیه (به عنوان مثال، rc.local یا sysctl.conf) تنظیم کنید.
اگر پارامترهای کرنل سیستم‌عامل را برای فعال‌سازی استفاده از صفحات بزرگ پیکربندی کنید، فرایندهای جاوا ممکن است صفحات بزرگ را هم برای هیپ جاوا (Java heap) و هم برای سایر بخش‌های داخلی تخصیص دهند، به عنوان مثال:
• 2
حافظهٔ نهان کد (Code cache)
• 2
بیت‌مپ‌های علامت‌گذاری (Marking bitmaps)
در نتیجه، اگر پارامتر nr_hugepages را به اندازهٔ هیپ جاوا تنظیم کنید، JVM همچنان ممکن است در تخصیص هیپ با استفاده از صفحات بزرگ با شکست مواجه شود، زیرا بخش‌های دیگری مانند حافظهٔ نهان کد ممکن است از قبل بخشی از صفحات بزرگ پیکربندی‌شده را مصرف کرده باشند.
"پشتیبانی از صفحات بزرگ در ویندوز (Large Pages Support for Windows)"
برای استفاده از پشتیبانی صفحات بزرگ در ویندوز، مدیر سیستم ابتدا باید امتیازهای اضافی را به کاربری که برنامه را اجرا می‌کند اختصاص دهد:
"1." 3
گزینهٔ Control Panel، سپس Administrative Tools و بعد از آن Local Security Policy را انتخاب کنید.
"2." 3
بخش Local Policies و سپس User Rights Assignment را انتخاب کنید.
"3." 3
روی Lock pages in memory دوبار کلیک کرده و سپس کاربران و/یا گروه‌ها را اضافه کنید.
"4." 3
سیستم خود را مجدداً راه‌اندازی کنید.
توجه داشته باشید که این مراحل حتی در صورتی که مدیر سیستم برنامه را اجرا کند نیز لازم است، زیرا مدیران سیستم به طور پیش‌فرض امتیاز قفل کردن صفحات در حافظه را ندارند.
"اشتراک داده‌های کلاس برنامه (APPLICATION CLASS DATA SHARING)"
قابلیت اشتراک داده‌های کلاس برنامه (AppCDS) کلاس‌های مورد استفادهٔ برنامه‌های شما را در یک فایل آرشیو ذخیره می‌کند.
از آنجا که این کلاس‌ها در قالبی ذخیره می‌شوند که بارگذاری آن‌ها بسیار سریع است (در مقایسه با کلاس‌های ذخیره‌شده در فایل JAR)، AppCDS می‌تواند زمان راه‌اندازی برنامه‌های شما را بهبود ببخشد.
علاوه بر این، AppCDS می‌تواند با به اشتراک‌گذاری بخش‌هایی از این کلاس‌ها در میان چندین فرایند، میزان مصرف حافظه در زمان اجرا را کاهش دهد.
کلاس‌ها در آرشیو CDS در قالبی بهینه‌سازی‌شده ذخیره می‌شوند که حدود ۲ تا ۵ برابر بزرگ‌تر از کلاس‌های ذخیره‌شده در فایل‌های JAR یا ایمیج زمان اجرای JDK است.
بنابراین، ایدهٔ خوبی است که فقط کلاس‌هایی را که واقعاً توسط برنامهٔ شما استفاده می‌شوند آرشیو کنید.
این کلاس‌ها معمولاً تنها بخش کوچکی از تمام کلاس‌های موجود هستند.
برای مثال، برنامهٔ شما ممکن است فقط از تعداد انگشت‌شماری از APIهای ارائه‌شده توسط یک کتابخانهٔ بزرگ استفاده کند..SS استفاده از بایگانی‌های CDS
به‌طور پیش‌فرض، در بیشتر توزیع‌های JDK، مگر اینکه -Xshare:off
مشخص شده باشد، JVM با یک بایگانی CDS پیش‌فرض راه‌اندازی می‌شود که
معمولاً در JAVA_HOME/lib/server/classes.jsa (یا
JAVA_HOME\bin\server\classes.jsa در ویندوز)
قرار دارد.
این بایگانی شامل حدود ۱۳۰۰ کلاس از کتابخانه‌های اصلی است که توسط
بیشتر برنامه‌ها استفاده می‌شوند.
برای استفاده از CDS جهت مجموعه دقیق کلاس‌های استفاده‌شده توسط برنامه خود،
می‌توانید از گزینه -XX:SharedArchiveFile استفاده کنید
که ساختار کلی آن به این صورت است:
-XX:SharedArchiveFile=<static_archive>:<dynamic_archive>
• 2
بخش <static_archive> جایگزین بایگانی پیش‌فرض CDS می‌شود.
• 2
بخش <dynamic_archive> کلاس‌های اضافی را فراهم می‌کند که
می‌توانند علاوه بر کلاس‌های موجود در <static_archive> بارگذاری شوند.
• 2
در ویندوز، نویسه جداکننده مسیر فوق : باید با ;
جایگزین شود.
نام‌های "static" (ایستا) و "dynamic" (پویا) به دلایل
تاریخی به‌کار رفته‌اند.
بایگانی پویا، اگرچه همچنان مفید است، نسبت به بایگانی CDS ایستا از
بهینه‌سازی‌های کمتری پشتیبانی می‌کند.
اگر مجموعه کامل بهینه‌سازی‌های CDS/AOT مد نظر است، استفاده از
کَش AOT که در ادامه توضیح داده شده را در نظر بگیرید.
ماشین مجازی جاوا (JVM) می‌تواند حداکثر از دو بایگانی استفاده کند.
برای استفاده از تنها یک <static_archive>، می‌توانید بخش
<dynamic_archive> را نادیده بگیرید:
-XX:SharedArchiveFile=<static_archive>
جهت سهولت کار، <dynamic_archive> مکان
<static_archive> را ذخیره می‌کند.
بنابراین، می‌توانید تنها با مشخص کردن مورد زیر، از ذکر <static_archive>
صرف‌نظر کنید:
-XX:SharedArchiveFile=<dynamic_archive>
ایجاد دستی بایگانی‌های CDS
بایگانی‌های CDS را می‌توان به‌صورت دستی با استفاده از چندین روش ایجاد کرد:
• 2
-Xshare:dump
• 2
-XX:ArchiveClassesAtExit
• 2
jcmd VM.cds
یک عملیات مشترک در تمام این روش‌ها، یک "اجرای آزمایشی" (trial run) است
که در آن برنامه را یک بار اجرا می‌کنید تا کلاس‌هایی که باید در بایگانی ذخیره
شوند تعیین گردند.
ایجاد یک فایل بایگانی CDS ایستا با -Xshare:dump
مراحل زیر یک فایل بایگانی CDS ایستا ایجاد می‌کند که شامل تمام کلاس‌های
استفاده‌شده توسط برنامه test.Hello است.
"1." 3
ایجاد فهرستی از تمام کلاس‌های استفاده‌شده توسط برنامه test.Hello.
دستور زیر فایلی به نام hello.classlist ایجاد می‌کند که
شامل فهرستی از تمامی کلاس‌های استفاده‌شده توسط این برنامه است:
4
java -Xshare:off -XX:DumpLoadedClassList=hello.classlist -cp hello.jar test.Hello
مسیر کلاس (classpath) مشخص‌شده با پارامتر -cp تنها باید
شامل فایل‌های JAR باشد.
"2." 3
ایجاد یک بایگانی ایستا به نام hello.jsa که شامل تمام
کلاس‌های موجود در hello.classlist است:
4
java -Xshare:dump -XX:SharedArchiveFile=hello.jsa -XX:SharedClassListFile=hello.classlist -cp hello.jar
"3." 3
اجرای برنامه test.Hello به همراه بایگانی
hello.jsa:
4
java -XX:SharedArchiveFile=hello.jsa -cp hello.jar test.Hello
"4." 3
اختیاری بررسی اینکه آیا برنامه test.Hello از
کلاس موجود در بایگانی اشتراکی hello.jsa استفاده می‌کند یا خیر:
4
java -XX:SharedArchiveFile=hello.jsa -cp hello.jar -Xlog:class+load test.Hello
خروجی این دستور باید شامل متن زیر باشد:
[info][class,load] test.Hello source: shared objects file
به‌طور پیش‌فرض، هنگامی که گزینه -Xshare:dump استفاده می‌شود،
JVM در حالت صرفاً مفسر (interpreter-only) اجرا می‌شود (همانند وضعیتی که گزینه
-Xint مشخص شده باشد).
این کار برای تولید خروجی قطعی و یکنواخت (deterministic) در فایل بایگانی
اشتراکی لازم است؛ یعنی دقیقاً همان بایگانی، بیت‌به‌بیت، با هر بار خروجی گرفتن
ایجاد خواهد شد.
با این حال، اگر خروجی قطعی لازم نباشد و فهرست کلاس (classlist) بزرگی دارید،
می‌توانید صراحتاً -Xmixed را به خط فرمان اضافه کنید تا
کامپایلر JIT فعال شود.
این کار روند ایجاد بایگانی را سرعت می‌بخشد..SS ایجاد فایل بایگانی پویای CDS با -XX:ArchiveClassesAtExit
مزایای بایگانی‌های پویای CDS عبارتند از:
• 2
آن‌ها معمولاً فضای دیسک کمتری مصرف می‌کنند، زیرا نیازی به ذخیره کلاس‌هایی که از قبل در بایگانی ایستا قرار دارند، ندارند.
• 2
آن‌ها در مقایسه با بایگانی ایستای متناظر، با یک مرحله کمتر ایجاد می‌شوند.
مراحل زیر یک فایل بایگانی پویای CDS ایجاد می‌کنند که شامل کلاس‌های استفاده‌شده توسط برنامه test.Hello است، به‌جز مواردی که از قبل در بایگانی پیش‌فرض CDS قرار دارند.
"1." 3
ایجاد یک بایگانی پویای CDS به نام hello.jsa که شامل تمام کلاس‌های موجود در hello.jar است که توسط برنامه test.Hello بارگذاری شده‌اند:
4
java -XX:ArchiveClassesAtExit=hello.jsa -cp hello.jar Hello
"2." 3
اجرای برنامه test.Hello با بایگانی اشتراکی hello.jsa:
4
java -XX:SharedArchiveFile=hello.jsa -cp hello.jar test.Hello
"3." 3
اختیاری مرحله ۴ از بخش قبلی را تکرار کنید تا مطمئن شوید برنامه test.Hello از کلاس موجود در بایگانی اشتراکی hello.jsa استفاده می‌کند.
همچنین می‌توان یک بایگانی پویای CDS را با یک بایگانی ایستای غیرپیش‌فرض CDS ایجاد کرد.
به عنوان مثال،
java -XX:SharedArchiveFile=base.jsa -XX:ArchiveClassesAtExit=hello.jsa -cp hello.jar Hello
برای اجرای برنامه با استفاده از این بایگانی پویای CDS:
java -XX:SharedArchiveFile=base.jsa:hello.jsa -cp hello.jar Hello
(در Windows، جداکننده مسیر : در بالا باید با ; جایگزین شود)
همان‌طور که در بالا ذکر شد، می‌توان از نام بایگانی ایستا صرف‌نظر کرد:
java -XX:SharedArchiveFile=hello.jsa -cp hello.jar Hello
ایجاد فایل‌های بایگانی CDS با jcmd
دو بخش قبلی برای ایجاد یک بایگانی CDS، نیازمند تغییر دادن اسکریپت راه‌اندازی برنامه هستند.
گاهی اوقات این کار ممکن است دشوار باشد؛ برای مثال، هنگامی که class path برنامه توسط روال‌های پیچیده‌ای تنظیم شده است.
دستور jcmd VM.cds با اتصال به یک پردازه در حال اجرای JVM، روشی با تداخل کمتر را برای ایجاد یک بایگانی CDS فراهم می‌کند.
شما می‌توانید یک بایگانی ایستا:
jcmd <pid> VM.cds static_dump my_static_archive.jsa
یا یک بایگانی پویا بسازید:
jcmd <pid> VM.cds dynamic_dump my_dynamic_archive.jsa
برای استفاده از فایل بایگانی حاصل در اجراهای بعدی برنامه بدون تغییر اسکریپت راه‌اندازی برنامه، می‌توانید از روش زیر استفاده کنید:
env JAVA_TOOL_OPTIONS=-XX:SharedArchiveFile=my_static_archive.jsa bash app_start.sh
نکته: برای استفاده از jcmd <pid> VM.cds dynamic_dump، پردازه JVM که با <pid> مشخص شده است باید با -XX:+RecordDynamicDumpInfo راه‌اندازی شده باشد، که می‌توان آن را نیز با همان روش به اسکریپت راه‌اندازی برنامه ارسال کرد:
env JAVA_TOOL_OPTIONS=-XX:+RecordDynamicDumpInfo bash app_start.sh
گزینه -XX:+AutoCreateSharedArchive روشی راحت‌تر برای ایجاد/استفاده
از آرشیوهای CDS است.
برخلاف روش‌های ایجاد دستی آرشیو CDS که در بخش قبلی شرح داده شد، با
-XX:+AutoCreateSharedArchive دیگر نیازی به یک اجرای آزمایشیِ
جداگانه نیست.
در عوض، می‌توانید همیشه برنامه را با همان خط فرمان اجرا کنید و به‌طور
خودکار از مزایای CDS بهره‌مند شوید.
java -XX:+AutoCreateSharedArchive -XX:SharedArchiveFile=hello.jsa -cp hello.jar Hello
اگر فایل آرشیو مشخص‌شده وجود داشته باشد و توسط همان نسخه از JDK ایجاد شده باشد،
به‌عنوان یک آرشیو پویا بارگذاری می‌شود؛ در غیر این صورت در زمان راه‌اندازی VM نادیده
گرفته خواهد شد.
در هنگام خروج VM، اگر فایل آرشیو مشخص‌شده وجود نداشته باشد، ایجاد خواهد شد.
اگر وجود داشته باشد اما با نسخه متفاوتی از JDK (البته پس از JDK 19) ایجاد شده باشد،
جایگزین خواهد شد.
در هر دو حالت، آرشیو آماده خواهد بود تا در راه‌اندازی بعدی JVM با همان خط فرمان
بارگذاری شود.
اگر فایل آرشیو مشخص‌شده وجود داشته باشد اما توسط نسخه‌ای از JDK قبل از JDK 19 ایجاد
شده باشد، نادیده گرفته خواهد شد: نه در زمان راه‌اندازی بارگذاری می‌شود و نه هنگام
خروج جایگزین می‌گردد.
توسعه‌دهندگان باید توجه داشته باشند که محتویات فایل آرشیو CDS مختص به هر بیلد
از JDK است.
بنابراین، اگر به بیلد متفاوتی از JDK مهاجرت کنید،
-XX:+AutoCreateSharedArchive به‌طور خودکار آرشیو را برای مطابقت
با JDK بازسازی خواهد کرد.
اگر قصد دارید از این ویژگی همراه با یک آرشیو موجود استفاده کنید، باید اطمینان
حاصل فرمایید که آرشیو حداقل با نسخه ۱۹ از JDK ایجاد شده باشد.
محدودیت‌های Class Path و Module Path
• 2
نه مسیر کلاس (-classpath و -Xbootclasspath/a)
و نه مسیر ماژول (--module-path) نمی‌توانند شامل دایرکتوری‌های
غیرخالی باشند.
• 2
تنها فایل‌های JAR ماژولار در --module-path پشتیبانی می‌شوند.
ماژول‌های بازشده (Exploded modules) پشتیبانی نمی‌شوند.
• 2
مسیر کلاسی که در زمان ایجاد آرشیو استفاده شده است باید با مسیر کلاسی که در زمان
اجرا استفاده می‌شود یکسان باشد (یا پیشوندی از آن باشد).
(هیچ الزامی از این دست برای مسیر ماژول وجود ندارد.)
• 2
اگر هر یک از فایل‌های JAR در مسیر کلاس یا مسیر ماژول پس از تولید آرشیو اصلاح شوند،
آرشیو CDS بارگذاری نخواهد شد.
گزینه‌های مرتبط با ماژول
گزینه‌های زیر در رابطه با ماژول‌ها توسط CDS پشتیبانی می‌شوند:
--module-path، --module،
--add-modules و --enable-native-access.
مقادیر این گزینه‌ها (در صورت تعیین شدن)، باید هنگام ایجاد و استفاده از آرشیو
CDS یکسان باشند.
در غیر این صورت، چنانچه هر یک از این گزینه‌ها تطابق نداشته باشند، آرشیو CDS ممکن
است به‌طور جزئی یا کامل غیرفعال شود که منجر به کاهش کارایی خواهد شد.
• 2
اگر گزینه AOTClassLinking (به زیر مراجعه کنید) در حین ایجاد آرشیو
CDS فعال بوده باشد، آرشیو CDS قابل استفاده نخواهد بود و پیام خطای زیر
چاپ می‌شود:
2
CDS archive has aot-linked classes. It cannot be used when archived full module graph is not used
• 2
اگر گزینه AOTClassLinking در حین ایجاد آرشیو CDS فعال
نبوده باشد، آرشیو CDS قابل استفاده است، اما ویژگی "archived module graph"
غیرفعال خواهد شد.
این امر می‌تواند به افزایش زمان راه‌اندازی منجر شود.
برای عیب‌یابی مشکلات مربوط به گزینه‌های AOT، می‌توانید -Xlog:aot را
به آرگومان‌های VM برنامه اضافه کنید.
به‌عنوان مثال، اگر در حین ایجاد آرشیو --add-modules jdk.jconsole مشخص
شده باشد و در زمان اجرا --add-modules jdk.incubator.vector مشخص گردد،
پیام‌های زیر لاگ خواهند شد:
Mismatched values for property jdk.module.addmods
runtime jdk.incubator.vector dump time jdk.jconsole
subgraph jdk.internal.module.ArchivedBootLayer cannot be used because full module graph is disabled
اگر هر یک از گزینه‌های VM شامل --upgrade-module-path،
--patch-module یا --limit-modules مشخص شده باشند،
CDS غیرفعال می‌شود.
این بدان معناست که JVM بدون بارگذاری هیچ آرشیو CDSای اجرا خواهد شد.
علاوه بر این، اگر تلاش کنید با مشخص کردن هر یک از این ۳ گزینه یک آرشیو CDS
ایجاد کنید، JVM خطایی را گزارش خواهد کرد..SH "حافظه نهان پیش‌ازموعد (AHEAD-OF-TIME CACHE)"
سامانه JDK از بهینه‌سازی‌های پیش‌از‌موعد (AOT) که می‌توانند پیش از اجرای برنامه انجام شوند، پشتیبانی می‌کند.
یک نمونه Class Data Sharing (CDS) است (همان‌طور که در بالا توضیح داده شد) که کلاس‌ها را پیش از موعد تجزیه می‌کند.
بهینه‌سازی‌های AOT می‌توانند عملکرد راه‌اندازی (start-up) و گرم‌شدن (warm-up) برنامه‌های Java را بهبود بخشند.
حافظه نهان پیش‌از‌موعد (AOT cache) یک نگه‌دارنده است که در JDK 24 برای ذخیره‌سازی دست‌ساخته‌های تولیدشده توسط بهینه‌سازی‌های AOT معرفی شده است.
حافظه نهان AOT در حال حاضر شامل کلاس‌های Java و اشیاء حافظه هیپ (heap) است.
در نگارش‌های آینده JDK، ممکن است حافظه نهان AOT شامل دست‌ساخته‌های بیشتری مانند پروفایل‌های اجرا و متدهای کامپایل‌شده نیز باشد.
یک حافظه نهان AOT مختص ترکیبی از موارد زیر است:
• 2
یک برنامه خاص (همان‌طور که توسط -classpath، -jar یا --module-path مشخص شده است).
• 2
یک نگارش خاص از JDK.
• 2
یک سیستم‌عامل و معماری پردازنده (CPU) خاص.
در صورت تغییر هر یک از موارد بالا، باید حافظه نهان AOT را دوباره بسازید.
استقرار حافظه نهان AOT به سه مرحله تقسیم می‌شود:
• 2
آموزش (Training): ما برنامه را با یک بار کاری نمونه اجرا می‌کنیم تا داده‌های آماری لازم برای مشخص کردن دست‌ساخته‌هایی که باید در حافظه نهان AOT گنجانده شوند را جمع‌آوری کنیم.
داده‌ها در یک فایل AOT Configuration ذخیره می‌شوند.
• 2
سرهم‌بندی (Assembly): ما از فایل پیکربندی AOT برای تولید یک حافظه نهان AOT استفاده می‌کنیم.
• 2
عملیات (Production): ما برنامه را همراه با حافظه نهان AOT برای دستیابی به عملکرد بهتر در راه‌اندازی و گرم‌شدن اجرا می‌کنیم.
حافظه نهان AOT می‌تواند با گزینه‌های خط فرمان زیر استفاده شود:
-XX:AOTCache=cachefile
مکان فایل حافظه نهان AOT را مشخص می‌کند.
پسوند استاندارد برای cachefile برابر با .aot است.
این گزینه نمی‌تواند همراه با -XX:AOTCacheOutput استفاده شود.
این گزینه با مقادیر on، create یا auto (پیش‌فرض) در تنظیمات AOTMode سازگار است.
فایل cachefile در حالت‌های AOT با مقادیر on و auto خوانده می‌شود و در حالت off نادیده گرفته می‌شود.
فایل cachefile توسط حالت AOT با مقدار create نوشته می‌شود.
در این صورت، این گزینه معادل با -XX:AOTCacheOutput=cachefile خواهد بود.
-XX:AOTCacheOutput=cachefile
مکان فایل حافظه نهان AOT را برای نوشتن مشخص می‌کند.
پسوند استاندارد برای cachefile برابر با .aot است.
این گزینه نمی‌تواند همراه با -XX:AOTCache استفاده شود.
این گزینه با مقادیر record، create یا auto (پیش‌فرض) در تنظیمات AOTMode سازگار است.
-XX:AOTConfiguration=configfile
فایل پیکربندی AOT را برای نوشتن یا خواندن توسط JVM مشخص می‌کند.
پسوند استاندارد برای configfile برابر با .aotconfig است.
این گزینه با مقادیر record، create یا auto (پیش‌فرض) در تنظیمات AOTMode سازگار است.
فایل configfile توسط حالت AOT با مقدار create خوانده شده و توسط سایر حالت‌های مرتبط نوشته می‌شود.
اگر حالت AOT برابر با auto باشد، گزینه AOTCacheOutput نیز باید مشخص شده باشد.
-XX:AOTMode=mode
حالت AOT را برای این اجرا تعیین می‌کند.
مقدار mode باید یکی از موارد زیر باشد: auto، off، record، create یا on.
• 2
auto: این حالت پیش‌فرض AOT است و در صورتی که گزینه -XX:AOTMode ارائه نشده باشد اعمال می‌شود.
این مقدار به‌طور خودکار حالت AOT را به شرح زیر روی record، on یا off تنظیم می‌کند:
2
• 2
اگر -XX:AOTCacheOutput=cachefile مشخص شده باشد، حالت AOT به record تغییر می‌یابد (یک اجرای آموزشی، به همراه عملیات بعدی create).
• 2
در غیر این صورت، اگر یک حافظه نهان AOT بتواند بارگیری شود، حالت AOT به on تغییر می‌یابد (یک اجرای عملیاتی).
• 2
در غیر این صورت، حالت AOT به off تغییر می‌یابد (یک اجرای عملیاتی بدون حافظه نهان AOT).
• 2
off: از هیچ حافظه نهان AOT استفاده نمی‌شود.
سایر گزینه‌های خط فرمان مربوط به AOT نادیده گرفته می‌شوند.
• 2
record: برنامه را در فاز آموزش اجرا می‌کند.
حداقل یکی از گزینه‌های -XX:AOTConfiguration=configfile و/یا -XX:AOTCacheOutput=cachefile باید مشخص شود.
اگر -XX:AOTConfiguration=configfile مشخص شده باشد، JVM داده‌های آماری را جمع‌آوری کرده و آن‌ها را در configfile ذخیره می‌کند.
اگر -XX:AOTConfiguration=configfile مشخص نشده باشد، JVM از یک نام فایل موقت استفاده می‌کند که ممکن است رشته AOTCacheOutput+".config" یا نام فایل موقت جدید و وابسته به پیاده‌سازی دیگری باشد.
اگر -XX:AOTCacheOutput=cachefile مشخص شده باشد، یک فرآیند دوم JVM برای انجام مرحله سرهم‌بندی اجرا می‌شود تا دست‌ساخته‌های بهینه‌سازی را در cachefile بنویسد.
2
گزینه‌های اضافی JVM را می‌توان با استفاده از متغیر محیطی JDK_AOT_VM_OPTIONS، با همان قالبی که برای متغیر محیطی JAVA_TOOL_OPTIONS وجود دارد و توسط JVMTI تعریف شده است
[https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#tooloptions]، به فرآیند دوم JVM ارسال کرد.
• 2
create: فاز سرهم‌بندی را انجام می‌دهد.
گزینه -XX:AOTConfiguration=configfile باید مشخص شده باشد.
سامانه JVM تاریخچه و آمارها را از configfile خوانده و دست‌ساخته‌های بهینه‌سازی را در cachefile می‌نویسد.
توجه داشته باشید که خود برنامه در این فاز اجرا نمی‌شود.
• 2
on: برنامه را در فاز عملیات (Production) اجرا می‌کند.
اگر -XX:AOTCache=cachefile مشخص شده باشد، JVM تلاش می‌کند تا cachefile را به عنوان حافظه نهان AOT بارگیری کند.
در غیر این صورت، JVM تلاش می‌کند تا یک default CDS archive را از دایرکتوری نصب JDK به عنوان حافظه نهان AOT بارگیری کند.
2
بارگیری حافظه نهان AOT ممکن است به دلایل متعددی با شکست مواجه شود:
• 2
تلاش می‌کنید از حافظه نهان AOT با یک برنامه، نگارش JDK، یا سیستم‌عامل/معماری ناسازگار استفاده کنید.
• 2
فایل cachefile مشخص‌شده وجود ندارد یا در دسترس نیست.
• 2
از گزینه‌های ناسازگار JVM استفاده شده است (برای نمونه، برخی گزینه‌های خاص JVMTI).
2
از آنجا که حافظه نهان AOT یک قابلیت بهینه‌سازی است، هیچ تضمینی وجود ندارد که با تمام گزینه‌های ممکن JVM سازگار باشد.
برای مشاهده فهرستی از سناریوهایی که ممکن است با حافظه نهان AOT ناسازگار باشند، به بخش Consistency of training and subsequent runs در JEP 483 [https://openjdk.org/jeps/483] مراجعه کنید.
این سناریوها معمولاً شامل تغییرات دلخواه روی کلاس‌ها برای مقاصد عیب‌یابی هستند و معمولاً به محیط‌های عملیاتی مربوط نمی‌شوند.
هنگامی که بارگیری حافظه نهان AOT با شکست مواجه می‌شود:
• 2
اگر AOTMode در ابتدا روی auto تنظیم شده بود، JVM به اجرای برنامه بدون استفاده از حافظه نهان AOT ادامه می‌دهد.
این حالت برای محیط‌های عملیاتی توصیه می‌شود، به‌ویژه زمانی که ممکن است کنترل کاملی روی خط فرمان نداشته باشید (مثلاً اسکریپت راه‌انداز برنامه شما ممکن است به کاربران اجازه دهد گزینه‌هایی را به خط فرمان اضافه کنند).
این امر به برنامه امکان می‌دهد به‌درستی به کار خود ادامه دهد، هرچند ممکن است از مزایای حافظه نهان AOT بهره‌مند نشود.
• 2
اگر AOTMode روی on باشد، JVM یک پیام خطا چاپ کرده و بلافاصله خارج می‌شود.
این حالت تنها باید به عنوان یک ابزار عیب‌یابی «شکست سریع» ("fail-fast") استفاده شود تا بررسی شود که آیا گزینه‌های خط فرمان شما با حافظه نهان AOT سازگار هستند یا خیر.
یک راهکار جایگزین، اجرای برنامه با -XX:AOTMode=auto -Xlog:aot است تا بررسی شود که آیا حافظه نهان AOT قابل استفاده است یا خیر.
-XX:+AOTClassLinking
اگر این گزینه فعال باشد، JVM هنگام ایجاد حافظه نهان AOT بهینه‌سازی‌های پیشرفته‌تری (مانند حل پیش‌ازموعد دستورالعمل‌های invokedynamic) را انجام می‌دهد.
در نتیجه، برنامه شاهد بهبودهای بیشتری در عملکرد راه‌اندازی و گرم‌شدن خواهد بود.
با این حال، یک حافظه نهان AOT که با این گزینه ایجاد شده باشد، در صورت مشخص شدن برخی پارامترهای خاص خط فرمان در فاز عملیات، قابل استفاده نخواهد بود.
لطفاً برای بررسی دقیق‌تر -XX:+AOTClassLinking و محدودیت‌های آن، به JEP 483 [https://openjdk.org/jeps/483] مراجعه کنید.
هنگامی که از -XX:AOTMode در خط فرمان استفاده شود، قابلیت AOTClassLinking به‌طور خودکار فعال می‌شود.
برای غیرفعال کردن آن، باید صراحتاً گزینه -XX:-AOTClassLinking را ارسال کنید.
هنگامی که از -XX:AOTMode در خط فرمان استفاده نشود، قابلیت AOTClassLinking به‌طور پیش‌فرض غیرفعال است تا سازگاری کامل با گزینه‌های سنتی CDS مانند `-Xshare:dump فراهم شود.
نخستین رخداد توالی ویژه %p در *configfile* و cachefile با شناسه فرایند (PID) فرایند JVM که در خط فرمان اجرا شده است جایگزین می‌شود، و به‌همین ترتیب نخستین رخداد %t با برچسب زمان راه‌اندازی JVM جایگزین می‌گردد.
(پس از جایگزینی، نباید هیچ رخداد دیگری از %p یا %t باقی بماند تا از بروز مشکل در زیرفرایندها جلوگیری شود.)
برای مثال:
java -XX:AOTConfiguration=foo%p.aotconfig -XX:AOTCacheOutput=foo%p.aot -cp foo.jar Foo
دو فایل ایجاد خواهد کرد: foopid123.aotconfig و
foopid123.aot، که در آن‌ها 123 شناسه فرایند JVM است
که برنامه Foo را اجرا کرده است.
"مثال‌های تنظیم کارایی (PERFORMANCE TUNING EXAMPLES)"
می‌توانید از گزینه‌های پیشرفته زمان اجرای جاوا برای بهینه‌سازی کارایی برنامه‌های خود استفاده کنید.
"تنظیم برای توان عملیاتی بالاتر"
از دستورات و گزینه‌های پیشرفته زیر برای دستیابی به کارایی و توان عملیاتی (Throughput) بالاتر در برنامه خود استفاده کنید:
java -server -XX:+UseParallelGC -XX:+UseLargePages -Xmn10g -Xms26g -Xmx26g
"تنظیم برای زمان پاسخ‌دهی کمتر"
از دستورات و گزینه‌های پیشرفته زیر برای دستیابی به زمان‌های پاسخ‌دهی کمتر در برنامه خود استفاده کنید:
java -XX:+UseG1GC -XX:MaxGCPauseMillis=100
"کوچک نگه‌داشتن Java Heap و کاهش ردپای حافظه پویای برنامه‌های تعبیه‌شده"
از گزینه‌های پیشرفته زمان اجرای زیر برای کوچک نگه‌داشتن Java heap و کاهش ردپای حافظه پویای برنامه‌های تعبیه‌شده (Embedded) استفاده کنید:
-XX:MaxHeapFreeRatio=10 -XX:MinHeapFreeRatio=5
نکته: مقادیر پیش‌فرض برای این دو گزینه به‌ترتیب 70% و 40% است.
از آنجا که استفاده از این مقادیر کوچک ممکن است به بهای فدا کردن کارایی تمام شود، باید با کاهش این تنظیمات تا حد امکان بدون ایجاد افت کارایی غیرقابل‌قبول، مصرف حافظه را بهینه‌سازی کنید.
"وضعیت خروج (EXIT STATUS)"
مقادیر خروج زیر معمولاً هنگامی توسط اجراکننده بازگردانده می‌شوند که با آرگومان‌های نادرست فراخوانی شود، یا خطاهای جدی و استثناهایی توسط JVM پرتاب شوند.
با این حال، یک برنامه جاوا می‌تواند با استفاده از فراخوانی API دستور System.exit(exitValue) هر مقداری را برگرداند.
این مقادیر عبارتند از:
• 2
0: اتمام موفقیت‌آمیز
• 2
>0: خطایی رخ داده است
2026 JDK 26.0.2.1