CODEWITHSUNDEEP
javamemory-managementgarbage-collectionjvm
Geek
Geek

Reputation: 27219

Why do JVM relocate objects in memory?

Modern JVM's sometimes relocates objects in memory during garbage collection even though the value of System.identityHashCode(object) remain the same for the lifetime of the object. What I do not understand is why do JVM relocate objects in memory?

Upvotes: 0

Views: 466

Answers (2)

Gray
Gray

Reputation: 116938

What I do not understand is why do JVM relocate objects in memory?

For posterity I thought it was good to summarize some comments on the other answer here. @assylias prolly should be writing this but he sounds busy. As @Ghostkeeper points out, one of the important benefits of relocatable objects is to lower (or remove) the problems inherent in memory fragmentation. Longer lasting smaller objects can be moved next to other objects of a similar size to open up contiguous free space for use by larger objects.

But an even more important reason why object relocation is so important is for memory and garbage-collection performance. Most modern JVMs implement a generational garbage-collector which maintains a number of different memory pools. These pools are often visible by using jconsole and connecting to your running application. See this answer for more info: How is the java memory pool divided?

Short term objects go into one pool and a high performance GC algorithm can run just on them since so many objects are immediately collected for reuse. By using information about the pool, the GC can easily determine that an object is unreachable without having to traverse the entire reference tree. For example, if you have a log-line like the following, the implied StringBuilder and resulting String are created and then can immediately be collected from the short-term object pool:

logger.info("automation run took " + diffMillis + "ms");
// when we reach this line, the StringBuilder and String are no longer in use

Because objects are relocatable, when the high performance GC algorithm finds an object in the short-term pool that is still in use, it is copied (relocated) to another pool and the references to the object are updated with the new location. Then the JVM has a clean short-term memory pool which it can begin to fill again. Objects in the mid-term or long-term memory pools are collected or relocated using more expensive GC algorithms (mark-and-sweep) that run less frequently. This ability to utilize different GC algorithms depending on which pool the object is in and being able to migrate objects between pools is a critical part of the modern, high-performance, GC systems in today's JVMs.

So the ultimate goal of relocatable objects is both overall memory performance and defragmentation.

Upvotes: 1

Ghostkeeper
Ghostkeeper

Reputation: 3050

If the memory gets fragmented (i.e. bits and pieces in between are removed) then memory access speed can be improved by defragmenting it. Moreover, defragmenting it opens up larger straits of memory, for large objects.

Edit for clarity: As posted in the comments below this answer, the Garbage Collection algorithms normally maintain 'zones' of memory. Some are meant to last long, and some are not. The algorithm differs on different JVMs, but it usually includes moving objects from one zone to the other in order to empty a zone completely, if it's already almost empty. That zone can then be made available as a whole. And the JVM is quite clever in discovering which objects are meant to last and which aren't, but sometimes it has to adapt its strategy and relocate an object.

Upvotes: 3

Related Questions