Java Visual Garbage Collection

Basis

When it comes to freeing up memory that is no longer used, garbage collection has largely replaced early technology, such as manual memory management and reference counting.

This is a good thing, because memory management is boring, and scholarly bookkeeping is something that computers excel at, not what people do well. In this respect, the language is more powerful than the human environment.

Modern garbage collection is highly efficient, much more than the typical manual distribution in earlier languages. In general, people with other language backgrounds only stare at the disruption caused by garbage collection, but do not fully understand the context in which automatic memory management takes effect.

Tag & Purge is the basic algorithm used by Java (and other runtime environments) for garbage collection.

In the markup & purge algorithm, the reference will point to the heap of the program from the stacks of each line. So, starting with the stack, follow the pointer to find all possible references, and then recursively follow the references.

When the recursion is complete, all the living objects are found, the others are rubbish.

Note that what people often miss is that the runtime environment itself also has a "allocation list", which lists pointers to each object, which is maintained by the garbage collector and helps the garbage collector with garbage cleanup. Therefore, the runtime environment can always find objects created by it but not yet reclaimed.

Figure A

The stack shown in the illustration above is just a stack associated with a single application thread; Each application thread has a similar stack, and each stack itself has a set of pointers to the heap.

If the garbage collector tries to get a snapshot of a live object while the application is running, it will have to track the moving target, so it is easy to miss out on the allocation of some seriously timed out objects, and thus cannot get an accurate snapshot. Therefore, "Stop the World" is necessary, that is, to stop the application thread long enough to capture a snapshot of the live object.

Here are the two golden rules that the garbage collector must follow:

1. The garbage collector must recycle all the garbage.
2. The garbage collector must never recycle any live objects.

But these two rules are not reciprocal, and if the second rule is violated, the result is that the data is compromised.

On the other hand, if the first rule is violated, it will be another case, the system is not always able to recycle all the garbage, but eventually it will reclaim all the garbage, then this is acceptable, and in fact, this is the basic principle of the garbage collector.

HotSpot

Now, let's say the hotspot, which is actually a mix of C, C + + and many platform-specific assembler programs.

When people think of an interpreter, they think of a large while loop that contains a very long switch statement. But the hotspot interpreter is much more complex than that (due to performance reasons). When you start reading the JDK source code, you will find that there are many assembler code in the hotspot.

Object Creation

Java will pre-allocate a lot of contiguous space, which is what we call "heap". The hotspot then manages this memory entirely in user space.

If a Java process takes up a large amount of system (or kernel) time, there is no doubt that it is not being garbage collected-because all of the garbage-collected memory "bookkeeping (bookkeeping)" is done in user space.

Memory Pool

Figure II

"Permanent Generation (PermGen)" is a storage area used to hold things that need to survive the lifetime of the program, such as metadata for a class. However, as the application server appears, they have their own classloader and need to reload the metadata of the class, and the permanent generation as an optimization decision starts to look bad, fortunately, it disappears in Java 8.

Java 8 will use a new concept called "meta-space (Metaspace)". The meta-space is not exactly the same as the permanent generation. It is outside of the heap, managed by the operating system. This means that it is not in the Java heap, but in local memory. Currently, this is not a very good news, because there are not many tools that make it easy for users to view local memory. So it's good to disappear forever, but it will take some time for the tool to catch up with the change.

Java Heap Layout

Now, let's look at the Java heap. Note the virtual space between heap spaces. They provide a bit of float to allow for a certain amount of sizing of the memory pool without paying the price for any object movement.

Might

"Weak generation hypothesis (Weak generational hypothesis)"

As far as the status quo is concerned, why should the heap be partitioned into all these memory pools?

Figure Four

Some runtime facts cannot be deduced from static analysis. The above illustration shows two groups of objects: a group of short survival times and a long surviving group-so it makes sense to do extra bookkeeping to take advantage of this fact. In the Java platform, there are many similar facts that are optimized for writing to the platform.

Demo

Ben Evans has a series of animated demos. The first demo is a flash that illustrates the process of moving objects between Eden and a Cenozoic survivor space and eventually into the old age.

Figure five reproduces the same process with JavaFX.

Figure Five

run-time switches

' Mandatory ' parameter

• -verbose:gc--output Some GC information for the user
• -xloggc:< file path >--Specify the log output path to ensure that the disk has space
• -xx:+pringgcdetails--provides "minimum information (Minimum information) for accessibility tools.

  --Use this parameter instead of-VERBOSE:GC

• --xx:printtenuringdistribution--"Premature ascension (premature promotion)" information

basic Heap Size parameters

• -xms<size> --Set the minimum memory value reserved for the heap
• -xmx<size> --Set the maximum memory value reserved for the heap
• -xx:maxpermsize=<size>--Set the maximum memory value for a permanent generation

  -Facilitates spring applications and application servers

Previously, we were taught to set the value of-XMS and-xmx as large. But it has changed. Therefore, it is now possible to set a reasonably small value for-XMS, or not at all, because the heap resilience is now very good.

Other Parameters

• -xx:newratio=n
• -xx:newsize=n
• -xx:maxnewsize=n
• -xx:maxheapfreeratio
• -xx:minheapfreeratio
• -xx:survivorratio=n
• -xx:maxtenuringthreshold=n

Figure Six

Why should I have a log file

The benefit of the log file is that it can be used for forensic analysis, which allows the user to avoid having to execute the code again for the sake of reproducing the problem (it is not easy to reproduce if it is a rare production environment error).

In addition, they contain more information than JMX Mxbeans for memory, and not that polling JMX itself introduces a series of GC issues.

Tools

• HP JMeter (check with Google)

  --free, very reliable, but no longer available support/feature enhancements

• Gcviewer

  --free, open source, but the interface is a little ugly

• Garbagecat

  --The best name to listen

• IBM GCMV

  --Support J9

• Jclarity Censum

  --The interface is the most beautiful, and most useful--but this is our prejudice!

Summary

• Need to understand some GC fundamentals
• To let most of the new generation die when they are young.
• Open the GC log! --The original log file is difficult to read--using tools
• use tools to help you tune -measure, not guess

Java Visual Garbage Collection