Use VisualVM to export the game heap dump and report memory issues

When the game shows the memory warning shown in the figure below, or memory usage keeps rising after repeatedly entering and exiting a save, you can export a heap dump as described in this article (.hprof), for developers to analyze. A heap dump records the objects in the Java heap and their reference relationships at the time of export.

High memory usage or warnings alone cannot prove that a memory leak exists. When reporting, please explain what you did before the issue occurred, and try to export while the game is still responsive after the issue appears; once you exit the game, you can no longer obtain the heap dump from that time.

• From VisualVM official websiteDownload and launch VisualVM.

• Launch the modpack that needs troubleshooting and try to reproduce the issue, for example by repeatedly entering and exiting the same save, or performing operations that cause memory to keep growing.

• Reserve enough disk space: heap dumps can reach several GB, and both generating temporary files and saving as files require space.

• The game may noticeably stall during export; please wait for the operation to complete.

1. On the left side of VisualVM, Applications → Local find the running Java process.

2. Double-click the candidate process, and in Overview use information such as the main class and the modpack instance path in the JVM arguments to confirm that it belongs to the current game; the process name varies depending on the launcher and launch method, so do not judge based only on whether it contains the word Prism.

3. Select the process that is actually running Minecraft. Do not select VisualVM, Gradle Daemon, Gradle Wrapper, or IntelliJ IDEA. When troubleshooting a standalone server, select the server's Java process.

The image below only shows the location of the process list; the game was not running when the screenshot was taken, and the selected Gradle Daemon is not the game process.

Switch to the target process's Monitor page, where you can see the heap memory curve, and in the upper right corner the Perform GC and Heap Dump buttons. The figure below still uses the Gradle Daemon to demonstrate the button positions; during actual operation, please confirm that the current tab belongs to the game process.

1. After reproducing the issue in the game, return to VisualVM's Monitor page and confirm that the Heap chart is updating.

2. If the developer asks you to observe the state after garbage collection, you can first click Perform GC, wait for the operation to complete, and note in your feedback that this operation was performed; for general collection, you can proceed directly to the next step without clicking repeatedly.

3. Click Heap Dump, and wait for the heap dump to be generated. The game may pause during this period; the time required depends on factors such as heap size. After it completes, VisualVM will show a heap dump node and open the corresponding tab.

4. In the Applications tree on the left, right-click the newly generated heap dump node and select Save As..., save it as .hprof file.

5. Wait for the save to complete, confirm in the save directory that the file has been generated, then exit the game.

After generating the heap dump, you also need to perform Save As. VisualVM official documentation states that heap dumps are only temporary files until explicitly saved. See Browsing a Heap Dump.

Submit issues through the feedback entry in the upper-right corner of the official website, or through the Issues entry of the GitHub repository provided on the official website..hprof If the file is large, you can first compress it into .zip or .gz; if the feedback entry cannot upload, use a file-sharing service to upload, and provide a downloadable link and any required extraction code in the feedback.

Please also provide the following information so that developers can reproduce the issue:

• Modpack version, Java version, and the maximum memory allocated to the game.

• Reproduction steps: what operations were performed, how many times they were repeated, and how long it took for an alert or obvious lag to appear.

• Status at export: still in the save file, or already returned to the main menu; whether it has been executed "Perform GC".

• .hprof file or download link, as well as this run's logs/latest.log; if there is a crash report, please attach it as well.

• VisualVM: Browsing a Heap Dump

• VisualVM: Working with Local Applications

• VisualVM: Getting Started with VisualVM

• VisualVM: Features

• Oracle Java: Troubleshoot Memory Leaks