Sparc: 512, Solaris x86: 320 (5.0以前 256), Sparc 64 bit: 1024, Linux amd64: 1024 (5.0 以前 0), 其他默认 512.
线程堆栈大小
-XX:+UseBiasedLocking
JDK 5 update 6后引入，但需要手动启用, JDK6默认启用
启用偏向锁
-XX:+UseFastAccessorMethods
默认启用
优化原始类型的getter方法性能(get/set:Primitive Type)
-XX:-UseISM
默认启用
启用solaris的ISM
-XX:+UseLargePages
JDK 5 update 5后引入，但需要手动启用, JDK6默认启用
启用大内存分页
-XX:+UseMPSS
1.4.1 之前: 不启用, 其余版本默认启用
启用solaris的MPSS，不能与ISM同时使用
-XX:+UseStringCache
默认开启
启用缓存常用的字符串。
-XX:AllocatePrefetchLines=1
1
Number of cache lines to load after the last object allocation using prefetch instructions generated in JIT compiled code. Default values are 1 if the last allocated object was an instance and 3 if it was an array.
-XX:AllocatePrefetchStyle=1
1
Generated code style for prefetch instructions. 0 – no prefetch instructions are generated, 1 – execute prefetch instructions after each allocation, 2 – use TLAB allocation watermark pointer to gate when prefetch instructions are executed.
Enables the use of compressed pointers (object references represented as 32 bit offsets instead of 64-bit pointers) for optimized 64-bit performance with Java heap sizes less than 32gb.
-XX:+AlwaysPreTouch
Pre-touch the Java heap during JVM initialization. Every page of the heap is thus demand-zeroed during initialization rather than incrementally during application execution.
-XX:AllocatePrefetchDistance=
Sets the prefetch distance for object allocation. Memory about to be written with the value of new objects is prefetched into cache at this distance (in bytes) beyond the address of the last allocated object. Each Java thread has its own allocation point. The default value varies with the platform on which the JVM is running.
-XX:InlineSmallCode=
当编译的代码小于指定的值时,内联编译的代码
-XX:MaxInlineSize=35
内联方法的最大字节数
-XX:FreqInlineSize=
内联频繁执行的方法的最大字节码大小
-XX:LoopUnrollLimit=
Unroll loop bodies with server compiler intermediate representation node count less than this value. The limit used by the server compiler is a function of this value, not the actual value. The default value varies with the platform on which the JVM is running.
-XX:InitialTenuringThreshold=7
设置初始的对象在新生代中最大存活次数
-XX:MaxTenuringThreshold=
设置对象在新生代中最大的存活次数,最大值15,并行回收机制默认为15,CMS默认为4
Garbage Collectors
The JVM (Java Virtual Machine) has several different garbage collectors, including the Parallel Scavenge collector and the G1 (Garbage-First) collector. Both collectors have a “young generation” that is responsible for storing newly created objects, but they work in different ways.
Parallel Scavenge collector
The Parallel Scavenge collector’s young generation, also known as the “PS young generation”, is divided into two regions called “Eden” and “Survivor”. The Eden region is where newly created objects are initially allocated, while the Survivor regions are used to store objects that have survived one or more garbage collection cycles. The idea is to quickly identify and collect objects that are no longer needed, while promoting long-lived objects to the older generation.
G1 collector
The G1 collector also has a young generation, which is referred to as the “G1 young generation”. Unlike the PS young generation, the G1 young generation does not have fixed regions like Eden and Survivor. Instead, the G1 collector divides the heap into equal-sized “regions” that can be used for both young and old objects, depending on their age and usage patterns. The G1 collector also uses a “remembered set” to keep track of references between regions, which allows it to more efficiently identify and collect objects that are no longer needed.
Overall, both the PS and G1 collectors have their own strengths and weaknesses, and the best choice depends on the specific requirements and characteristics of the application. The G1 collector is generally considered to be more flexible and adaptive to different usage patterns, but the PS collector may be better suited for applications with short-lived objects and high object creation rates.
