0

I'm rather new to Java, and I would like to know the structure of different versions of HotSpot JVM Garbage Collectors and principles of garbage collection process (I'm interested mostly in the ones used in Java 1.6, 1.7 and 1.8), but unfortunately I couldn't find the one extensive source to cover this topic in Java.

  1. Could you recommend me some references where I can read more about different versions of HotSpot JVM Garbage Collectors?

  2. Is Permanent Generation segment the part of JVM Heap? Oracle OBE tutorials say that it is: "The heap parts are: Young Generation, Old or Tenured Generation, and Permanent Generation" (Source) But Mark Nelson speaks about Permanent Generation and Heap separately (Source).

  3. And is it true that string literals are stored in Heap, but not in the Permanent Generation starting from 1.7 Java version? (Source)

  4. Where in JVM are the primitives stored? Is it heap or permanent generation?

  5. Where in JVM are the constants stored? Is it heap or permanent generation?
Community
  • 1
  • 1
invaa
  • 23
  • 6
  • Hello! I've made changes to my post, please review it and unhold. I think it is more isolated now. – invaa Sep 03 '14 at 17:55

2 Answers2

0

The link is a little bit old but i hope it helps

http://cs.williams.edu/~freund/cs434/hotspot-gc.pdf

Also might wanna check

http://mechanical-sympathy.blogspot.com.br/2013/07/java-garbage-collection-distilled.html

The last one helped me a lot when tunning the JVM for all kinds of stuff, its a good read anyway.

catacavaco
  • 55
  • 1
  • 1
  • 10
0

There are multiple garbage collectors in Java; but the popular one to study was the "eden" and aging model.

Of course, now that most people are running the G1 garbage collector, even that popular model is often not describing what is really taking place. Don't get too worried about the inaccuracy, for quite a few releases, it was the de-facto default.

Garbage collection is about two primary tasks, reclaiming memory and hole compaction.

  1. Reclaiming memory is done conceptually first. If the JVM cannot reach the object from a non-dead thread, then the object is reclaimed (as it cannot become part of the executing program in the future... the knowledge of the handle / address of the object has been permanently lost).
  2. Once objects have been reclaimed, they leave the heap in a "swiss cheese" state, with some regions being used, and other regions empty (due to reclaiming). Compaction attempts to remove the "holes" in the heap in such a way that attempts to allocate large objects will not fail because the memory requested is not available as a contiguous series of addresses.

With the old eden style garbage collectors, the ideas were that

  1. Newly created objects were at higher risk of being reclaimed because they probably were created within the scope of a block (and the references would probably be lost when exiting the block).
  2. Less-newly created objects were at lower risk of being reclaimed because they survived the block they were created in.

As such, the "eden" space was the part of the heap where an object wasn't yet checked to see if it was still reachable by the JVM program execution threads. Survivor space was where the object was copied into (copying allowed re-basing of the addresses and thus compaction), and other more permanent spaces indicated an even longer-lived object.

Now with the new G1 garbage collector, you effectively have thousands (to millions) of mini-heaps, and the entire heap is marked based on the survivability of the objects it contains. Compaction is occasionally done by combining two "heap blocks"; however, since the heaps are so much smaller, often they are just discarded instead of compacted (due to higher chance of all objects in a heap being unreachable when fewer objects are to be considered).

Edwin Buck
  • 69,361
  • 7
  • 100
  • 138
  • Note that at less-than-half heap usages, often they default algorithm is to "copy and sweep", which roughly means, when I detect an object is being used, I copy it into the other half of memory, and when done detecting, I sweep the old half clean. The the process repeats back into the swept side. It has some distinct performance benefits (despite the copy) due to it's simplicity in the compaction approach. – Edwin Buck Sep 03 '14 at 08:10
  • Thank you a lot. But could you please tell me, where all the constants and string literals are stored in the JVM? And is it correct to say that perm gen is the part of the JVM heap? – invaa Sep 03 '14 at 12:27
  • Most of the true literals are initially defined within the `.class` file's constant pool. Perm gen is not really part of the heap, because once it goes into perm gen, it cannot really be reclaimed. However, in Java 8, what would have been stored in perm gen is now stored in the heap (and can be reclaimed, in theory, except that by the time it hits permanent generation, it is not clear when (if ever) it would be appropriate to reclaim it). If the JVM decides to unpack the class and internalize all constants in a central location, that's an implementation detail of the JVM, not a requirement. – Edwin Buck Sep 03 '14 at 15:00
  • And keep in mind that all classes have their variable data holding structures on the heap, but seldom do they have their constants and code pages in the same exact memory space. For memory compactness, the executable instructions of the class are often stored once, regardless of the number of instances. This tends to imply that the constants are also stored once-per-class, regardless of instances. Finally it depends on the JVM implementation. I could see some implementations trading speed for space, effectively interning all the strings, I just don't know of an example that does it. – Edwin Buck Sep 03 '14 at 15:02