{"id":223068,"date":"2022-01-31T18:32:12","date_gmt":"2022-01-31T17:32:12","guid":{"rendered":"https:\/\/blog.jetbrains.com\/?post_type=idea&p=223068"},"modified":"2024-07-31T10:43:02","modified_gmt":"2024-07-31T09:43:02","slug":"fixing-the-parrot-party","status":"publish","type":"idea","link":"https:\/\/blog.jetbrains.com\/pt-br\/idea\/2022\/01\/fixing-the-parrot-party","title":{"rendered":"Profiling Tutorial: Fixing the Parrot Party"},"content":{"rendered":"

We often find ourselves in situations where code is not working properly, and we have no idea where to even begin investigating.<\/p>\n

Can\u2019t we just stare at the code until the solution eventually comes to us? Sure, but this method probably won\u2019t work without deep knowledge of the project and a lot of mental effort. A smarter approach would be to use the tools you have at hand. They can point you in the right direction.<\/p>\n

\"\"<\/p>\n

In this post, we\u2019ll look at how we can use some of IntelliJ IDEA\u2019s built-in tools to investigate a runtime problem.<\/p>\n

Note:<\/b> This post shows how to use features of both the Community and Ultimate versions of IntelliJ IDEA. To use the profiling tools<\/a>, make sure you have IntelliJ IDEA Ultimate.<\/p>\n\n\n

The problem<\/h1>\n\n\n

Let\u2019s start with cloning the following repository: https:\/\/github.com\/flounder4130\/party-parrot<\/a><\/p>\n

Launch the application using the Parrot run configuration included with the project. The app seems to work well: you can tweak the animation color and speed. However, it\u2019s not long before things start going wrong.<\/p>\n

After working for some time, the animation freezes with no indication of what the cause is. There can also be a OutOfMemoryError<\/code>, whose stack trace doesn\u2019t tell us anything about the origin of the problem.<\/p>\n

\"A<\/p>\n

There is no reliable way of telling how exactly the problem will manifest itself. The interesting thing about the animation freeze is that we can still use the rest of the UI.<\/p>\n

Important:<\/b> We run this using Amazon Corretto 11. The result may differ on other JVMs or even on Corretto 11 if it uses a custom configuration.<\/p>\n\n\n

Debugger<\/h1>\n\n\n

It seems we have a bug. Let\u2019s try using the debugger! Launch the application in debug mode, wait until the animation freezes, then hit Pause<\/b>.<\/p>\n

\"The<\/p>\n

Unfortunately, this did not tell us much because all the threads involved in the parrot party are in the waiting state. We don\u2019t even know if the threads are waiting for a lock or have just finished their current work. Clearly, we need to try another approach.<\/p>\n\n\n

CPU and Memory Live Charts<\/h1>\n\n\n

Since we are getting an OutOfMemoryError<\/code>, a good starting point for analysis is CPU and Memory Live Charts<\/b>. They allow us to visualize real-time resources usage for the processes that are running. Let\u2019s open the charts for our parrot app and see if we can spot anything when the animation freezes.<\/p>\n

\"Memory<\/p>\n

Indeed, we see that the memory usage is going up continually before reaching a plateau. This is precisely the moment when the animation hangs, and there seems to be no way out of this.<\/p>\n

This gives us a clue. Usually, the memory usage curve is saw-shaped: the chart goes up when new objects are allocated and periodically goes down when the memory is reclaimed by the garbage collector. You can see an example of this in the picture below:<\/p>\n

\"Normal<\/p>\n

If the saw teeth become too frequent, it means that the garbage collector is having a hard time trying to reclaim the memory. A plateau means it can\u2019t free up any.<\/p>\n

We can test it by requesting garbage collection from CPU and memory live charts<\/b>.<\/p>\n

\"GC<\/p>\n

Memory usage does not go down after our app reaches the plateau. This supports our hypothesis that there are no objects eligible for garbage collection.<\/p>\n

A na\u00efve solution would be to just add more memory.<\/p>\n

\"Specifying<\/p>\n

However, regardless of the available memory, the parrot runs out of memory anyway. Again, we see the same picture. The only visible effect of extra memory was that we delayed the end of the “party”.<\/p>\n

\"The<\/p>\n\n\n

Allocation Profiling<\/h1>\n\n\n

Since we know our application never gets enough memory, we might want to analyze its memory usage.<\/p>\n

Let\u2019s run the application with Async Profiler attached. It\u2019s a great choice for CPU profiling. But that\u2019s not all \u2013 starting with version 2.0, which is integrated into IntelliJ IDEA, we get the ability to profile memory allocations as well.<\/p>\n

Note:<\/b> If you\u2019re on Windows, use Java Flight Recorder for allocation profiling.<\/p>\n

\"Launching<\/p>\n

While running, the profiler records the application state when objects are placed on the heap. This data is then aggregated in a human-readable form to give us an idea of what the application was doing when allocating these objects.<\/p>\n

After running the profiler for some time, let\u2019s open the report and see what\u2019s there.<\/p>\n

\"Click<\/p>\n

There are several views available for the collected data. In this tutorial, we will use the flame graph. It aggregates the collected stacks in a single stack-like structure, adjusting the element width according to the number of collected samples. The widest elements represent the most massively allocated types during the profiling period.<\/p>\n

\"Click<\/p>\n

An important thing to note here is that a lot of allocations don\u2019t necessarily indicate a problem. A memory leak happens only if the allocated objects are not garbage-collected. While allocation profiling doesn\u2019t tell us anything about the garbage collection, it can still give us hints for further investigation.<\/p>\n

Let\u2019s see where the two most massive elements, byte[]<\/code> and int[]<\/code>, come from. The top of the stack tells us that these arrays are created during image processing by the code from the java.awt.image<\/code> package. The bottom of the stack tells us that all this happens in a separate thread managed by an executor service. We aren\u2019t looking for bugs in library code, so let\u2019s look at the user code that\u2019s in between. <\/p>\n

Going from top to bottom, the first application method we see is recolor()<\/code>, which in turn is called by updateParrot()<\/code>. Judging by the name, this method is exactly what makes our parrot move. Let\u2019s see how this is implemented and why it needs that many<\/i> arrays.<\/p>\n

\"Click<\/p>\n

Clicking at the frame and selecting Jump to Source<\/b> takes us to the source code of the corresponding method:<\/p>\n

\"The<\/p>\n

It seems that updateParrot()<\/code> takes some base image and then recolors it. In order to avoid extra work, the implementation first tries to retrieve the image from some cache. The key for retrieval is a State<\/code> object, whose constructor takes a base image and a hue.<\/p>\n\n\n

Analyzing Data Flow<\/h1>\n\n\n

Using the built-in static analyzer, we can trace the range of input values for the State<\/code> constructor call. Right-click the baseImage<\/code> constructor argument, then from the menu, select Analyze<\/b> | Data Flow to Here<\/b>.<\/p>\n

\"\"<\/p>\n

Expand the nodes and pay attention to ImageIO.read(path.toFile())<\/code>. It shows us that the base images come from a set of files. If we double-click this line and look at the PARROTS_PATH<\/code> constant that is nearby, we discover the files location:<\/p>\n

\"\"<\/p>\n

That\u2019s ten base images that correspond to the possible positions of the parrot. Well, what about the hue<\/code> constructor argument?<\/p>\n

\"\"<\/p>\n

If we inspect the code that modifies the hue<\/code> variable, we see that it has a starting value of 50<\/code>. Then it is either set with a slider or updated automatically from the updateHue()<\/code> method. Either way, it is always within the range of 1<\/code> to 100<\/code>.<\/p>\n

So, we have 100 variants of hue and 10 base images, which should guarantee that the cache never grows bigger than 1000 elements. Let\u2019s check if that holds true.<\/p>\n\n\n

Conditional Breakpoints<\/h1>\n\n\n

\nNow, this is where the debugger can be useful. We can check the size of the cache with a conditional breakpoint.<\/p>\n

Let\u2019s set a breakpoint at the update action and add a condition so that it only suspends the application when the cache size exceeds 1000 elements.<\/p>\n

\"\"<\/p>\n

Now run the app in debug mode.<\/p>\n

\"\"<\/p>\n

Indeed, we stop at this breakpoint after running the program for some time. So we can be sure that the problem is in the cache.<\/p>\n\n\n

Inspecting the Code<\/h1>\n\n\n

Cmd<\/b> + B<\/b> on cache<\/code> takes us to its declaration site:<\/p>\n

private static final Map<State, BufferedImage> cache = new HashMap<>();<\/code><\/p>\n

If we check the documentation for HashMap<\/code>, we\u2019ll find that its implementation relies on the equals()<\/code> and hashcode()<\/code> methods, and the type that is used as the key has to correctly override them. Let\u2019s check it. Cmd<\/b> + B<\/b> on State<\/code> takes us to the class definition.<\/p>\n

Seems like we have found the culprit: the implementation of equals()<\/code> and hashcode()<\/code> isn’t just incorrect. It’s completely missing!<\/p>\n\n\n

Override Methods<\/h1>\n\n\n

Writing implementations for equals()<\/code> and hashcode()<\/code> is a mundane task. Luckily, IntelliJ IDEA can generate them for us. While in the State<\/code> class, start typing equals<\/code>, and the IDE will understand what we want.<\/p>\n

\"\"<\/p>\n

Just accept the suggestion and click Next<\/b> until the methods appear at the caret.<\/p>\n

\"\"<\/p>\n

Hint:<\/b> You can also use this as a quick way to override other members or generate accessor methods. For example, typing get<\/code> will show you the suggestions to generate getter methods.<\/p>\n\n\n

Checking the Fix<\/h1>\n\n\n

Let\u2019s restart the application and see if things have improved. Again, we can use CPU and Memory Live Charts<\/b> for that:<\/p>\n

\"\"<\/p>\n

That is much better!<\/p>\n\n\n

Summary<\/h1>\n\n\n

In this post, we looked at how we can start with the general symptoms of a problem and then, using our reasoning and the variety of tools IntelliJ IDEA offers us, narrow the scope of the search step-by-step until we find the exact line of code that’s causing the problem. More importantly, we made sure that the parrot party will go on no matter what!<\/p>\n

If you are interested in more detailed instructions on how to use the features from this post, feel free to check out the documentation:<\/p>\n