Difference between JDK 32bit and 64bit

Theoretically, a 32-bit JVM has a 4G heap size limit.
However, due to various constraints such as swap area, kernel address space usage, memory fragmentation, and management overhead of the virtual hypervisor, the actual available heap size is far less than the theoretical 4G.
On a 32-bit Windows machine, the heap can be up to 1.4G to 1.6G.
On a 32-bit solaris machine, the heap can reach a maximum of 2G
On a 64-bit operating system, a 32-bit JVM, the heap size can reach 4G

In addition, when using the java parameter -xms -xmx to define the heap size,
1. If the 32bit jvm exceeds 4G, it is definitely useless. 4G is defined, and only 2G may be used in the end.
2. These two values ​​are best defined as the same, which can reduce the operation of java gc and have a small performance improvement

JVM is an essential tool for Java developers, and JVM is also available in 32 bit and 64 bit.
So what is the difference between 32-bit and 64-bit JDK actually?
The difference between JVM 32bit and JVM 64bit is as follows:
1. Currently only server VM supports 64bit JVM, client does not support 32bit JVM.
2.The Java Plug-in, AWT Robot and Java Web Start these components currently do not support 64bit JVM
3. The impact of native code: There is no impact on the JNI programming interface, but code written for 32-bit VM must be recompiled to work on 64-bit VM.
4. The maximum heap size of a 32-bit JVM is 4G. On 64-bit VMs, the size of the Java heap is limited by physical memory and virtual memory provided by the operating system. (heap is not rigorous here)
5. The default stack size of threads: On Windows 32-bit JVM, the default stack size is 320k, and 64-bit JVM is 1024K.
6. Performance Impact:
(1) Compared with the 32bit JVM, the 64bit JVM has less performance loss in the case of a large number of memory accesses. When the AMD64 and EM64T platforms run in 64-bit mode, the Java virtual machine gets some extra registers, which can be used with to generate more efficient native instruction sequences.
(2) In terms of performance, on SPARC processors, when a java application is ported from a 32bit platform to a 64bit JVM on a 64bit platform, it will use about 10-20% performance loss, while on AMD64 and EM64T platforms, its performance loss is The range is 0-15%.

JVM performance analysis
It is written on Sun's official website that when a java application is ported from a 32bit platform to a 64bit JVM on a 64bit platform, the application will suffer performance losses, and I believe many people will be puzzled.
From a numerical point of view, we generally think that a 64-bit JDK is better than a 32-bit JDK, but as mentioned above, "in fact, under a 32-bit application, the performance of a 32-bit processor will be even stronger, even if it is a 64-bit processor, the current situation The performance is also stronger in 32bit applications."
Many of the simple truths in the Datong world include that the bigger the better, it is not the case when it is moved to the computer field. When dealing with multiple CPUs, you'll find the extra processing units of those multiple cores useful, but if your work is only single-threaded, all you need to do is let the other cores sit on the sidelines.
The 32-bit vs. 64-bit comparison is more nuanced. The x86-64 architecture not only increases the registers on the basis of the x86 architecture, but also increases the number of registers. Basically this leads to better performance (because more registers allow the compiler to create better machine code). Unfortunately, shifting Java from 32-bit to 64-bit has brought only a performance drop so far.
The Java Virtual Machine (JVM) is a software specification, and its 32-bit and 64-bit versions have different performances, but they both include a JIT compiler and garbage collection (GC), and the performance key lies in the JIT compiler and garbage collection. execution efficiency. The JIT compiler implements dynamic translation from Java bytecode to hardware machine code before program execution. The idea behind it is
, compared to Java source code, bytecode is smaller and easier to compile, but at the cost of taking a little time to compile Java bytecode to machine code, which is different from compiling Java source code directly to machine code. Than, time is still much less.
In 32-bit and 64-bit JVMs, the corresponding JIT takes slightly different time to compile Java bytecode into final machine code, but some optimizations can be made;
In addition, the overall performance will vary between the IBM and Sun versions of the client and server programs. Garbage collection reclaims memory that objects no longer need to use, and it must be performed frequently to free the Java heap that objects no longer access.
Since on 32-bit and 64-bit platforms, the size of the data in the Java heap will change, it will be due to the performance difference between 32-bit and 64-bit JVMs. However, the larger the pointer, the more difficult the GC management, resulting in the performance of the corresponding garbage collection. will vary.