Turn: JNI high-performance program development

• 1. Try not to create global reference and global weak reference. Create the JNI interfaces newglobalreference and newglobalweakreference for these two types of references.
  There is a lock. This lock makes the scalability of the multi-processor very poor, because each thread is waiting for this lock. Therefore, try not to save the reference of a Java object in native. Instead, add the vertex parameter to each JNI call. Of course, it is very dangerous to keep the local reference of a Java object in native.

  2. Do not use getprimitivearraycritical/releaseprimitivearraycritical to pin the Java memory. The JVM itself does not provide any operations that only pin a piece of Java memory without affecting GC. Therefore, this operation will prevent GC. As compensation, releaseprimitivearraycritical generates an implicit GC call. This may cause GC failure when GC is required, but meaningless GC is not required. In addition, the implementation of these two operations may also trigger the lock in some cases.
  Solution: if it is a small block of memory, you prefer to use getarrayregion and setarrayregion to copy the memory between native and Java.

  3. Try not to create a phantom reference or soft reference in Java appliation. These references greatly affect GC.
  Let's talk about jvm gc first. GC is divided into minor GC and full GC. Java memory is divided into two generations: young and old. In young memory, each thread has its own memory allocation block (not shared with other threads), while old memory is shared by all threads. Minor GC only performs GC on young memory, while full GC performs GC on all memory. Minor GC can be executed in parallel in multiple threads, while full GC can only be executed in a single thread by default. Therefore, a full GC may take more than 10 times as long as minor GC (you can use-verbose: GC for observation ). Therefore, in general applications, the number of minor GC times should be about 10 times that of full GC. Minor GC will move uncollected objects to the old memory.
  Minor GC does not collect phantom reference and soft reference. Only full GC does. This problem is that a large number of such objects are accumulated, resulting in a lot of memory replication. In this way, each minor GC may basically not release much memory, so that full GC will be triggered frequently. The number of times of minor GC and full GC may be, or even full GC. In this way, both performance and scalability are very poor.
  The Influence of weak reference seems to be smaller, but it should be avoided as much as possible.
  In JNI development, the main purpose of using these three types of reference is to ensure the release of Native Resources. Because the Finalize method of Java objects is not guaranteed to be called, these references must be used to release Native Resources. To avoid the above problems, a feasible method is to make native resource serialize into a piece of memory and save it in a Java object to avoid using these references.

  4. Nio is a good way to share memory between Java and native. But pay attention to its performance. First, you must set big endian or little endian to prevent JVM from performing additional Endian conversion operations. The second step is to add the-server option when starting JVM, otherwise NiO performance will be very poor. In-server mode, NiO performance is about 30% ~ slower than Java array ~ 50%. In-client mode, the performance difference is more than doubled.

  5. Try not to use the new Java String object in JNI. This is much slower than new in the Java layer.

  6. For Java large objects (such as arrays), be sure to carefully tune the size of tune. Generally, small objects are GC-friendly. Because the young memory of each thread is first viewed during object allocation
  If enough memory is found, allocate it. Otherwise, it is allocated in the old memory. Because old memory is shared, there may be lock overhead. And the objects in the old memory are only
  Only full GC can be released. Therefore, it is better to have a small object. The JVM memory allocation algorithm is optimized for small objects, and the allocation of a large number of small objects is very efficient, so you don't have to worry about small objects.
  In some cases, if you know that the object will survive for a long time, you can increase it to increase the probability that it is directly allocated to the old memory. This saves the overhead of copying this object to the old memory by young GC.