When the garbage collector eliminates the object, where does that object go?

Question

Let's say garbage collector has identified an instance of a class (an object) - which is not being used by the Java Program. So the Garbage Collector decides to eliminate that object since it is not being used anywhere in the code. Now, when the elimination of an object happens, where does the object go inside the memory? What actually happens to that object inside the memory? In general term - when the object is eliminated - how the computer handles the elimination? how the elimination works?

My question is more about - what happens after the elimination of an object inside the heap happens. (in Java)

Few things I can think of which may be happening here are: the memory of that object (inside the heap) now becomes free, but the object still remains in the system, and since the memory is available, newly created objects can take its space. so if I think in binary format: 1s and 0s of previous object are going to be overwritten by new sequences of 1s and 0s (new object).

In your answer, please provide answers in this format:

1. What actually happens to the garbage collected object?
2. What are the names of these processes called in Java or in computer science terms?

Note: I tried to find the similar question/answer on stackoverflow, but this question is specific, so I couldn't find the answer, thus I had to post a question.

Answer 1

What actually happens to that object inside the memory? In general term - when the object is eliminated - how the computer handles the elimination? how the elimination works?

Memory is not given back to the operating system directly. Memory is now free to use for future object allocations for the JVM. This means there is no explicit deletion, the memory of the object that references now free to use. Because memory allocation from OS is already done by JVM, only in some GC memory is given back to the system which also its frequency/behavior can be set explicitly with GC params but it is complicated operation since it comes with a cost.

There are ongoing works for optimizing this behavior, e.g: look at the openjdk 12 hotspot work for it: https://openjdk.java.net/jeps/346

Answer 2

You got misled by the commonly used term “garbage collector”, which is a misnomer. The “garbage collector” does not collect garbage.

So your question starts with the wrong premise:

Let's say garbage collector has identified an instance of a class (an object) - which is not being used by the Java Program. So the Garbage Collector decides to eliminate that object since it is not being used anywhere in the code.

Neither of these two things happens. The garbage collector will not identify individual unused objects and it won’t “destroy” any object, as destruction of objects is not a thing.

A garbage collector works by determining which objects are still in use, typically by traversing all object references, starting at a root set, i.e. local variables of still running threads and static fields of classes loaded by the bootstrap loader.

When it knows, which objects are still in use, the gaps between those objects are reclaimable memory, regardless of how many objects were previously stored in there. It may simply add those chunks of memory to a list of available memory, but most modern garbage collectors will relocate the objects still in use, to get contiguous blocks of free memory, to enable fast allocations and prevent fragmentation.

So

1. What actually happens to the garbage collected object?

Nothing happens to a “collected” object. The dead objects are entirely irrelevant to the process.

2. What are the names of these processes called in Java or in computer science terms?

The general term still is “garbage collection” even if its literal meaning doesn’t describe the actual process. Sometime it’s called “memory management”, which fits better, as usually, the memory manager is also responsible for the allocations and thus, also determines how the heap is organized.

In typical implementations, you may identify subtasks as

• Marking
  The process of identifying objects still in use (also known as tracing)
• Sweeping
  The process of going through the gaps and either, add them to a list of free memory or prepare them for one of the following processes:
• Copying
  Relocate alive objects of a particular memory region into a new region, so that the source region is entirely free afterwards
• Compacting
  Relocate some alive objects of a particular memory region withing the same region, filling the gaps, so that the region has contiguous free memory at the beginning or end

Answer 3

1) The memory where that object is allocated is just marked as free by the garbage collector. Java has a continuous memory space allocated on the beginning (imagine allocating a huge pointer in c or c++) when you are creating an object the memory management system is putting it there (object x is allocated between n and m addresses) when the object is deleted the gc is just marking n and m as free. The process is more complicated, but you can imagine it like this in simple terms (you can read about generations and compacting for a better understanding :)

2) In simple terms the gc runs on a thread started at the app start of a Java application. Some important terms: generations (types of address spaces), heap (the address space where the memory is allocated)

Answer 4

Nothing happens.

An object isn't really a "living being". In the end, it is just: bytes in memory. And a bit of information that the JVM keeps: "this object here is 'alive'" (used by other objects that are alive), and "here is the memory that belongs to that object".

Now, when the GC "collects" the object, what happens conceptually: the JVM simply drops "I got this object here with memory there" from its internal data structure. And most likely, that information like "x bytes of freed memory at address y" is stored in some other data structure within the JVM. So that the JVM knows: that previously occupied memory is now available to re-use it for another object.

That can very well lead to: that memory location sits there, unchanged for quite some time. Until the JVM needs more memory, and decides to reuse that "space" for a different purpose.