Optimizing Memory Usage for Efficient HRC Calculations

This article provides guidance on managing memory limits in HoldemResources Calculator (HRC) to ensure smooth and efficient calculations. Learn how to adjust memory settings, monitor usage, and troubleshoot potential issues.

Adjusting Memory Limit

By default, HRC uses a memory limit of 4GB. This limit determines the number of hands that can be loaded at once and the size of trees that can be calculated. To utilize more memory, you can increase the default limit by editing the hrc.ini configuration file.

Follow the steps below to adjust the limit:

  1. Locate the hrc.ini file in the installation directory. On Windows right-click the HRC launcher and select Properties and then Open File Location.
  2. Open hrc.ini in a text editor and find the -Xmx setting near the end of the file.

Screenshot of hrc.ini

  1. Update the -Xmx limit, for example, change the line to -Xmx8G for an 8GB limit. Be sure to stay within the recommended maximum size for your system's installed physical memory.
Physical RAMmax. Xmx
8GB4G - 6G
16GB~ 12G
32GB~ 26G
64GB~ 56G
128GB~ 120G
  1. You generally don't need to update the -Xms setting, which defines the minimum amount of memory that Java will reserve.

  2. Save hrc.ini and restart HRC.

Monitoring Memory Usage in HRC

Insufficient memory or incorrect memory limit configurations can cause problems and crashes with HRC. As a Java-based program, HRC runs within a Java Virtual Machine (JVM), which allocates memory from your operating system and manages this memory for HRC.

You can monitor the live heap usage in HRC using the status bar in the bottom right corner of the program:
Idle heap

When no calculations are actively running, click the garbage can icon next to the bar to trigger a garbage collection. This clears all temporary data and displays the remaining non-temporary memory usage of loaded hands, abstractions, and so on. Triggering garbage collection manually is for information purposes only, as it is performed automatically when needed.

Hovering your mouse over the status bar will display additional information in a tooltip. In this example, HRC uses 892MB of heap space out of 2376MB currently allocated by the JVM, which would be the memory usage displayed by the Windows Task Manager. The memory limit is set to 4096MB (4GB), and the JVM could allocate additional memory up to that limit if needed.

During sampling, the memory status will behave like this:
Heap status during a calculation

The bar should constantly fill up towards the right side and then jump back by a significant amount. This is normal behavior, as temporary data is created during the calculation process and later cleared by the JVM garbage collector. As long as the bar occasionally clears below 80-85%, things are perfectly fine.

Troubleshooting Memory Issues

Memory issues can typically be categorized into three types:

  1. HRC runs out of space within the JVM (hitting the -Xmx limit)
    The memory status bar gets stuck towards the maximum and HRC may display memory related error messages. This is the most common cause of problems.
  2. Java fails to allocate more space (-Xmx limit is set too high)
    If HRC closes without an error message and creates crash log files in the HRC directory (hs_err_pid*.log) then the JVM likely fails to allocate additional memory.
  3. Hardware failures or instabilities
    While less common, hardware issues can also cause crashes without an error message.

See the sections below for more information.

HRC Runs Out of JVM Heap Space

The most common issue is HRC exhausting the maximum heap space allowed by the -Xmx setting. Typically this will result in error messages like an "Out of memory exception" or "Insufficient heap space", but it can also cause seemingly unrelated errors like "Nullpointer exceptions".

Heap space full

When HRC runs out of heap space the memory status bar gets stuck at well over 95% and will barely move. The JVM is not allowed to allocate additional memory due to the -Xmx setting, but all the space within the JVM is occupied by non-temporary data that can't be cleared by the garbage collector. Java keeps running garbage collections in an attempt to clear space and HRC may become unresponsive.

Options to fix this:

  • Free up space within HRC by closing open hands.
  • Reduce the tree complexity, e.g. by using fewer and larger bet sizes.
  • Increase the memory limit if sufficient is RAM available on your system.

We generally recommend keeping about 15% of heap space free; otherwise, performance may degrade slightly.

JVM is unable to allocate additional memory

The JVM reserves memory from the operating system up to the limit you specified. If it tries to allocate more memory than is physically available, this can cause the JVM to shut down (HRC "crashes" without an error message). Alternatively, the OS may try to make room for HRC by killing other processes or starting to swap. It's best to avoid this scenario.

Ensure that the specified memory limit is actually available and leaves enough room for your operating system and other programs. HRC will use some additional memory on top of the specified heap limit, so reserve at least 1-2 GB extra space in addition to the memory limit. It's better to stay on the conservative side with the -Xmx limit to avoid any issues.

Hardware stability issues

If you've ruled out the issues above and HRC continues to crash, this may result from a hardware issue. Try running stress tests to check for hardware stability problems.

Prime95 can quickly identify CPU instabilities, which could result from faulty hardware, insufficient cooling, incorrect BIOS configuration, or unstable overclocking. While Prime95 can test memory to some extent, it's less reliable for this purpose. For a more in-depth memory test, use Memtest86+.

Prime95: https://www.mersenne.org/download/

Memtest86+: https://www.memtest.org/