Introduction and problem analysis of Java break Memory on IBM i

Introduction

Many users who use IBM Java virtual machines often have the question of whether my program should use a 32-bit JVM or a 64-bit JVM.

As we know, the 32-bit JVM has the following advantages over 64-bit JVMS:

Fast boot speed

Fast running speed

For the same application, less system resources are consumed

Obviously, the 32-bit JVM is the user's first choice. However, with 32-bit addressing, the 32-bit JVM's usable memory space is much smaller than that of 64-bit, so there are times when users have to use 64-bit JVMs. Users often ask the question: How much memory does my Java job really need?

To answer this question, first understand the memory structure of the Java job. The memory consumed by the Java application Runtime consists of two parts: the Java Heap and the break Memory. In contrast, the Java Heap is a familiar term that refers to the space prepared for Java object, which is managed by the JVM's garbage collection mechanism. Break Memory is also a term for JVM memory.

This article mainly discusses the break Memory, also introduces the memory allocation model of the JVM on IBM I and how to judge the problem is the outofmemory on the break Memory.

What is a break memory

The break Memory is also called internal or private memory relative to Heap Memory. A break Memory is a space that is applied in the JVM through a malloc way, specifically, it is used by the following sections:

Thread Stacks

C + + code for the JVM

The Native function code of the user and the Native function of Pase

To better understand the memory structure, a 32bit memory space chart is given below (table 1):

In this diagram, you can see that the program's memory is divided into 16 partitions, each partition is 256M, such a program occupies 256*16 = 4G space. This layout of program memory has the following characteristics:

Several memory partitions are scheduled for other purposes, and these partitions cannot be used as Java Heap or break Memory.

The total amount of space used by Heap Memory and break Memory is fixed and they collectively occupy these intervals. On table 1, the space from 0x3 to 0xC is the break Memory and Heap Memory.  Break Memory allocates space from the 0x3 partition, and the memory space is reserved for Heap Memory from the 0xC partition in the reverse direction of the partition. The more partitions the Heap Memory occupies, the fewer partitions the break Memory can use, and vice versa.

When any part of a partition is used as a Heap Memory, the entire partition is retained for this particular purpose, and break Memory no longer use this partition.

When the JVM is started, it can be set to the maximum memory space (-XMX) reserved by the Heap Memory, and the default is 2GB.

Many times, the program does not set the Heap Memory size. In this default scenario, the allocation layout for memory is:

Heap Memory occupies 8 partitions, 2048M. (2048/256 = 8)

There are 6 memory partitions to run the JVM for other purposes, including the kernel, application text, stack data, shared class library text, and so on.

The remaining 2 memory partitions are reserved for break Memory: (total)-(8 heap)-(6 reserved) = 2

Another common scenario is to set the Heap Memory maximum of 1500M, at this point:

Heap Memory occupies 6 partitions, (1500/256 = 5.8)

As above, there are 6 memory partitions for other purposes

4 partitions Left (1024 MB) left to break memory

Figure 1. Standard mode