Reprinted from the product is slightly net: http://www.pinlue.com/article/2020/03/0422/199981849836.html
JVM recent study, understand some knowledge about the JVM memory allocation and garbage collection, which is a real optimization Eclipse startup, load time from classes, JIT compilation time, garbage collection time three optimized, simple , comprehensive, can deepen understanding of the JVM, so here validate it.
Hardware and operating system environments:
Java version (HotSpot Virtual Machine):
Eclipse-related information:
The original startup configuration:
The maximum permanent generation of space is 256M, the initial heap 40M, the largest 512M
GC information to start using the tool to view jvisualvm:
Use the eclipse plug-in to start the count of the eclipse.
Optimization class loading speed:
See jstat -class ID using the class loader, the original as follows:
Considering the time does not need to reload the bytecode verification, so the parameter -Xverify: none prohibit off bytecode verification process. Class load time becomes optimized, reduced to about half the original time:
Optimizing build time:
Compile time is a virtual machine JIT (just in time compiler) hot code compiler takes, virtual machine bytecode slow interpreted by the virtual machine built in runtime compiler, the hot code is compiled to native instant code to improve speed.
-Xint parameters prohibit the operation of the compiler, to force the virtual machine to execute bytecode pure interpreted.
When the virtual machine is running when -client mode, using a lightweight compiler code-named C1.
When the virtual machine is running in -server mode when using a compiler, code-named heavyweight C2 to provide more optimizations. This does not reduce compile time, but the long run will benefit.
Optimize garbage collection times:
Eclipse startup process on this machine were 12 times Minor GC, 2 times Full GC, described memory allocation is quite reasonable. If too many Minor GC number, indicating that the new generation of space allocation is too small, can be used to adjust the new generation -Xmn space.
As for the Old Gen's old, it did not reach the maximum capacity has undergone a number of Full GC is mainly due to expansion caused years old.
Permanent space on behalf of Perm Gen expansion will bring part of the time overhead.
In order to avoid expansion performance brought waste, and can -Xms -XX: PermSize -Xmx parameters are set and -XX: PermSizeMax parameter value, such that the maximum space and the space is equal to the initialization. Such virtual machine on startup took years old and permanent generation capacity fixed down.
Optimizing garbage collector:
Considering the low CPU utilization, you can try using the parallel collector. -XX: + UseConcMarkSweepGC and -XX: + UseParNewGC. The ability to take full advantage of multi-core CPU can be reduced GC pauses. Note that the old default CMS's used on 68% of the collection, can be used if necessary -XX: CMSInitiatingOccupancyFraction = 85 to modify the thresholds of 85%.
The last eclipse of the startup configuration optimization is completed as follows:
-startup
plugins/org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.200.v20140116-2212
-product
org.eclipse.epp.package.jee.product
--launcher.defaultAction
openFile
-showsplash
org.eclipse.platform
--launcher.defaultAction
openFile
--launcher.appendVmargs
-vmargs
-Dosgi.requiredJavaVersion=1.6
-Xverify:none
-Xms512m
-Xmx512m
-Xmn171m
-XX:MaxPermSize=256m
-XX:PermSize=128m
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
Minor GC can be seen only four times (500ms), and Full GC is not occurred, space 340M old age is not a direct extension. Permanent space on behalf of initialization is initialized to half of the maximum of 256M 128M.
In addition, if space is ample years old but still occurred Full GC, you can try close to System.gc () explicitly calls, -XX: + DisableExplicitGC.
-Vmargs parameters mean setting JVM parameters, so they are actually JVM parameters, and we need to know about the mechanism behind the JVM memory management, and then explain what each parameter represents. Heap (Heap) and non-heap (Non-heap) memory according to the official statement: "Java virtual machine has a heap that is the runtime data area from which memory for all class instances and arrays are allocated from here heap in a Java virtual. created when the machine starts. "" in addition to the JVM heap memory is called non-heap memory (non-heap memory) ". JVM can be seen mainly manage two types of memory: heap and non-heap. In short stack is Java code and memory, is left to the developer used; non-JVM heap is left to their own use, so the method area, JVM internal processing or optimization of memory required (such as the JIT compiled code cache), the structure of each class (e.g., runtime constant pool, field and method data) and code for methods and constructors are in a non-heap memory. JVM heap memory allocation from the initial allocation specified memory -Xms, default physical memory 1/64; JVM is specified by the maximum memory allocated -Xmx, 1/4 default physical memory. Default heap spare memory is less than 40%, JVM stack will increase up to a maximum limit of -Xmx; spare time is greater than the heap memory 70%, JVM will reduce the minimum limit of the stack until -Xms. Thus servers generally disposed -Xms, equal -Xmx heap size to avoid adjustment after every GC. Non-heap memory allocation used by the JVM -XX: PermSize initial value setting non-heap memory, physical memory default 1/64; manufactured by XX: MaxPermSize size of the largest non-heap memory is provided, the default is 1/4 of the physical memory. JVM memory limit (maximum) first JVM memory limits to the actual maximum physical memory (nonsense! Ha ha), assuming that the physical memory is infinite, then, the maximum JVM memory with the operating system has a great relationship. Simply put on the 32-bit processor, although controllable memory space 4GB, but the operating system will give a specific limit, the limit is generally lower 2GB-3GB (generally Windows systems 1.5G-2G, the Linux system 2G-3G), and more than 64bit processors there would be no limit.
