[Go] Use Java Mission control for memory allocation analysis

Jdk7u40 comes with a very handy tool, Java Mission Control. JRockit Misson control users should be familiar with the many functions of mission control, and JRockit is also a great tool. This article will focus on how to use the Java Flight Recorder for memory allocation analysis.

The JVM has a great chunk of memory virtualization technology, which gives you a sense of the illusion of having unlimited memory, in fact it costs a lot. Sometimes the JVM needs to find out how the data on the heap is being used and expand the remaining space-this is garbage collection. The reason for this is that the actual physical memory that the JVM obtains is limited and therefore requires memory reclamation and reuse when it is not being used. In some time-sensitive applications, such as trading systems and communication programs, these pauses are intolerable. There are many GC tuning methods to avoid this kind of pause. It seems that the above discussion is irrelevant. The way to make the GC less is of course to minimize the allocation of memory.

Sometimes, you want to find out which places in your program are causing the stress of memory allocation. There are many reasons for this kind of pressure. The most common scenario might be that the JVM needs a regular GC, and the time is far beyond the reasonable value you think.

JFR Assigning events

The Java Flight Recorder (JFR) implemented in HOTSPOT7U40 has two memory allocation events that can help us find out where memory is allocated in the program: Memory allocations in Tlab and memory allocation events outside Tlab.

Similar to most other events provided by the JDK, there is a series of analysis interfaces that can be customized in Mission control. It takes us a few minutes to discuss the actual events before we do the analysis.

First, you need to make sure that the event is nearly logged. If you use the default template option, you will find that the memory allocation analysis option is turned off by default. Either open it or use the analysis template instead of the default template. The memory analysis option is turned off by default because it may cause too many events. and for different programs its performance consumption is uncertain, because different programs in the case of the difference in the storage and distribution is very large.

The log label in the event label group is the perfect address for viewing each individual event. Let's take a look at what's included here:

This includes the exact size of the allocated memory, the stack track that caused the memory allocation, the class that allocates the memory, and the event information. In Tlab memory allocation events, they also include the allocated Tlab size.

It is important to note that Tlab memory allocation events do not correspond to memory allocation events for each location, which consumes resources too much. Instead, we escalate the event only when memory is allocated for the first time in the new Tlab. This means that we only get a sample of the local thread's memory allocation after some sort.

Also, it is important to note that the TLA events we use in JRockit are identical to the allocations made in the Cenozoic, with large object allocation events and Laosheng memory allocations. But these are a bit complicated in the hotspot. Memory allocation events outside of Tlab can be the same as a young generation of memory collections, or as a direct large object assignment for subsequent Eden and old areas. In other words, if you find some small amount of memory allocation outside of the Tlab event, you don't need to worry. In normal terms, this is a very rare situation. So these distinctions are not so obvious in the real situation.

Using the Allocation tab page

The Allocation (Allocation) tab actually contains three sub-tabs:

1. General
2. New Tlab Assignment
3. Tlab outside distribution

The Generic tab provides a total view and statistics for some of the available events, such as the total memory allocated for different event types. Depending on your primary goal, the way you treat this information will be different. The following example is very concise and focuses on the internal Tlab allocation because it focuses more on the total memory allocation pressure.

The new Tlab assignment provides more than three types of virtualization that are specifically designed to analyze new Tlab allocation events: Class-level, thread-level, and analysis-level allocations. Analysis-level allocation is a simple collection of stack traces for these three types. As we can see from this example, the integer object accounts for almost all the memory allocations of the entire system. Selecting an integer class in the histogram displays a collection of stack traces for all the memory of the integer object, and in this case all allocations are from the same location, as shown.

Tlab the Memory tab and the new Tlab tab work the same way, only at this point in time is consistent, of course, these are tlab events outside.

Limit

Because the new Tlab memory allocation event is just a sample of the total thread local memory allocation, only one event is difficult to illustrate. More events will have a more accurate picture. In addition, if the behavior of the allocation event varies greatly during recording, it is also difficult to establish a very convincing view of the local memory allocation.

Original link: Hirt translation: importnew.com-Pan
Link: http://www.importnew.com/13346.html
[ Reprint please keep the source, translator and translation links.] ]

[Go] Use Java Mission control for memory allocation analysis