2

I was faced with this question recently for the different types of heap memory available in Java.

I couldn't find much information online. Are there different types of heap memory available in Java ?

5

Heap is divided Young Generation, Old or Tenured Generation, and Permanent Generation.

The Young Generation is where all new objects are allocated and aged. When the young generation fills up, this causes a minor garbage collection. Minor collections can be optimized assuming a high object mortality rate. A young generation full of dead objects is collected very quickly. Some surviving objects are aged and eventually move to the old generation.

The Old Generation is used to store long surviving objects. Typically, a threshold is set for young generation object and when that age is met, the object gets moved to the old generation. Eventually, the old generation needs to be collected. This event is called a major garbage collection.

The Permanent generation contains metadata required by the JVM to describe the classes and methods used in the application. The permanent generation is populated by the JVM at runtime based on classes in use by the application. In addition, Java SE library classes and methods may be stored here.

enter image description here

Refer Oracle Java documentation for more details:

"Browse to JVM Generations"

  • 6
    Note that this answer is specific to implementation details of Oracle's Hotspot VM. Other virtual machines (and indeed future versions of Hotspot) may be different. The question asked generically about "Java" which includes all possible implementations; the answers below address that. – Jules May 12 '17 at 10:38
10

While the other answers are giving good information about the internal details of certain various JVM heap designs, from the programmer's perspective, there is only one heap and one way to use it -- via new for allocation and via letting go for deallocation.

Thus, I would say that there is no availability of different kinds or areas of a Java heap for programmers to concern themselves with.


Of course, sometimes understanding how to get to the last ounce of JVM performance for your application requires knowledge of some of these internal details.


(There are some APIs that support memory mapped files, but those are generally not considered a heap, especially in the sense of calling them Java heaps. Java does not allocate objects (e.g. via new) in memory mapped files.)

  • 4
    And let's not forget that there are implementations of Java outside of a JVM. – Jörg W Mittag May 11 '17 at 23:36
  • @JörgWMittag, yes; I was trying to imply that though it is good to call it out explicitly. – Erik Eidt May 11 '17 at 23:40
  • Indeed, the different GC generations are all part of the same heap from the programmer's perspective. But the PermGen (now the poorly-named Metaspace) is a distinct area for classes, constants, and interned strings. – Jerry101 May 11 '17 at 23:42
  • 3
    @Jerry101, interesting point, though just to be clear for the OP, that is also implementation detail to a particular JVM, and, it does not affect the programming model, but more tuning your app to this particular JVM implementation. – Erik Eidt May 12 '17 at 4:42
7

tl;dr summary:

I couldn't find much information online. Are there different types of heap memory available in Java ?

Short answer: No.

Slightly longer answer: The Java Language Specification does not say anything about different types of heap memory. It doesn't say that there have to be different types, it also doesn't say that there mustn't be different types. Implementors are free to choose to implement heap in whatever way they wish.

Slightly surprising answer: The Java Language Specification does in fact not really say anything about a "heap" at all. I think it would be possible to create a conforming implementation that doesn't use a heap.

Long answer:

There are 25 occurrences of the term "heap" in the Java Language Specification.

21 of those occurrences are the compound term "heap pollution", which is just a name given by (originally) Sun to a particular situation where Java's type system in unsafe. It doesn't actually have anything to do with "the heap":

It is possible that a variable of a parameterized type will refer to an object that is not of that parameterized type. This situation is known as heap pollution.

2 of those occurrences are the compound term "heap memory", which is just a name given by (originally Sun) to shared memory between threads:

Memory that can be shared between threads is called shared memory or heap memory.

Only 2 of the 25 occurrences are about "the heap". One of those occurrences is in a non-normative section, i.e. it is not actually part of the specification.

This leaves only one occurrence of the term "heap" in the entire 788 pages of the Java Language Specification, and it is in the section on how to correctly implement finalization, mentioned once (bold emphasis mine):

Optimizing transformations of a program can be designed that reduce the number of objects that are reachable to be less than those which would naively be considered reachable. For example, a Java compiler or code generator may choose to set a variable or parameter that will no longer be used to null to cause the storage for such an object to be potentially reclaimable sooner.

Another example of this occurs if the values in an object's fields are stored in registers. The program may then access the registers instead of the object, and never access the object again. This would imply that the object is garbage. Note that this sort of optimization is only allowed if references are on the stack, not stored in the heap.

This is the only time that it even gets implied that there is such a thing as "the heap" in Java. And it doesn't say anything about what "the heap" is, and it certainly doesn't say anything about how it's organized. There is no mention of "different types of heap memory" anywhere in the entire Java Language Specification, so we can pretty confidently say that there is no such thing as "different types of heap memory" in Java.

And it makes sense, really: the Java Language Specification is very careful in omitting details that would constrain implementors from innovating in the area of performance, and memory management is certainly an area that is both performance-sensitive itself and has performance implications for user programs.

  • Nice one, going to the language instead of some implementation. – Deduplicator May 12 '17 at 10:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.