Java GC notes

verbose:gc

verbose:gc prints right after each gc collection and prints details about each generation memory details. Here is blog on how to read verbose gc

If you are trying to look for memory leak, verbose:gc may not be enough. Use some visualization tools like jhat (or) visualvm etc.,

4416K->512K(4928K), 0.0081170 secs

Before GC used memory is 4416K After GC used memory is 512K Total allocated memory is 4928K

-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:C:/Users/tzhang17/temp/gc/gc.log

a typical ratio of YoungGen vs. OldGen is 1:3 or 33%.

Minimizing the frequency of major GC collections is a key aspect for optimal performance so it is very important that you understand and estimate how much memory you need during your peak volume.

Again, your type of application and data will dictate how much memory you need. Shopping cart type of applications (long lived objects) involving large and non-serialized session data typically need large Java Heap and lot of OldGen space. Stateless and XML processing heavy applications (lot of short lived objects) require proper YoungGen space in order to minimize frequency of major collections.

Generational collection

According to the generational hypothesis [21], most objects die young and consequently older objects tend to live longer. Generational collection capitalises on the generational hypothesis by dividing the available memory space into multiple regions called generations. Garbage collector passes are less frequent as the generations grow older and objects are always allocated into the newest generation. If the object survives a garbage collection, it is promoted to an older generation. Each generation can have a separate garbage collection strategy.

Reference counting

Reference counting uses a counter per object to record the number of references to the object. The pointer is incremented each time a reference towards the object is created. The object is reclaimed when its reference count drops to zero. Reference counting is being extensively used by scripting languages such as Perl.

GC strategy

Mark-Sweep garbage collection is most times followed by a compaction phase in order to avoid memory fragmentation. The compaction phase requires moving the objects to adjacent memory locations, thus making Mark-Sweep quite an expensive algorithm for large memory multiprocessor environments, unless a multithreaded heap compactor is employed. Simple reference counting is also unsuitable for high throughput environments because it requires objects to be reclaimed on pointer updates; if a pointer is removed and the reference count of the pointed object drops to zero, the runtime system is required to collect both that object and the objects it references. Furthermore, a major drawback of reference counting is its inability to collect circular data structures, such as doubly linked lists. Despite its drawbacks, the simplicity in the implementation of reference counting made it the preferred garbage collection strategy in runtime environments with a limited lifetime, such as scripting languages.

mutable memory

Memory in a typical JVM is organised in a series of mutable (garbage collected) and immutable zones. Class code is usually loaded in immutable space1 and remains there until the JVM is stopped. Also, the code emitted from the JIT compiler is temporarily stored in immutable space. The actual allocations take place in the heap, which is a contiguous memory area.

Apart from the class member values, each object also contains additional data such as a pointer to the respective class methods and flags related to locking and garbage collection. In most virtual machines, object headers take up to 8–12 bytes of additional storage space for each object, and can therefore sadle a program with significant performance and space overhead. A lot of work has been put into compacting the object header [6], which, in some cases, resulted in space savings of up to 20%.

A failure to allocate space for an object triggers a garbage collection cycle. The root set is determined by conservatively scanning the stacks of running or suspended threads and the current values of the processor registers for potential pointers to the heap. Root set acquisition can also be a performance bottleneck in the case when a large number of threads is executed concurrently, though these costs can be amortised using clever co-operation of the garbage collector with the JIT.

JDK 1.5

Sun’s JVM is an implementation of the 1.5 version of the Java language specification. It features an adaptive optimising JIT compiler, the well-known Hotspot engine, and a choice of three garbage collectors [2, 12]. Sun’s JVM is based upon a generational copying garbage collector that utilises two generations Figure 1 presents the heap organisation, which is shared among all collectors. Allocations initially occur in the eden space and survivors are promoted to one of the survivor spaces in a copying fashion. Optionally, portions of the heap space can be allocated to individual threads (Thread-Local Heaps (TLHs)), in order to speed up allocations on large-heap multithreaded environments. Objects that reach a certain age threshold, usually measured in minor garbage collection cycles, are copied to the tenured generation where they are left untouched until a major collection occurs. A mark-compact garbage collector is used for the tenured generation.

Tuning advise

• Unless you have specific hardware constraints, devote as much memory as you can to the virtual machine. A big heap size offers the opportunity for less frequent, albeit more time consuming, full heap collections. In a throughput-oriented environment sacrificing pause times to allow more CPU time for the executed application is often a good compromise. Do not allow the virtual machine to be swapped out to disk, as this is catastrophic for performance. In an application server that only runs a single virtual machine, you could devote about 90% of its available RAM to it and turn off paging, without risking the failure of either the virtual machine or the operating system.
• Calculate the memory allocation rate for your application. It is a significant measurement that you should perform by exposing the application to full workload. Its impact varies depending on the underlying hardware. As a rule of thumb, on a multiprocessor machine, each processor could easily generate more than 150MB of garbage per second. High allocation rates can be efficiently dealt with by using parallel collectors or large eden heap sizes.

Committed heap

A MemoryUsage object represents a snapshot of memory usage. Instances of the MemoryUsage class are usually constructed by methods that are used to obtain memory usage information about individual memory pool of the Java virtual machine or the heap or non-heap memory of the Java virtual machine as a whole. A MemoryUsage object contains four values:

init represents the initial amount of memory (in bytes) that the Java virtual machine requests from the operating system for memory management during startup. The Java virtual machine may request additional memory from the operating system and may also release memory to the system over time. The value of init may be undefined. used represents the amount of memory currently used (in bytes). committed represents the amount of memory (in bytes) that is guaranteed to be available for use by the Java virtual machine. The amount of committed memory may change over time (increase or decrease). The Java virtual machine may release memory to the system and committed could be less than init. committed will always be greater than or equal to used. max represents the maximum amount of memory (in bytes) that can be used for memory management. Its value may be undefined. The maximum amount of memory may change over time if defined. The amount of used and committed memory will always be less than or equal to max if max is defined. A memory allocation may fail if it attempts to increase the used memory such that used > committed even if used <= max would still be true (for example, when the system is low on virtual memory). Below is a picture showing an example of a memory pool: +———————————————-+ +//////////////// | + +//////////////// | + +———————————————-+

    |--------|
       init
    |---------------|
           used
    |---------------------------|
              committed
    |----------------------------------------------|

Garbage Collection for JVM

Interpreting vs compile

• The HotSpot JVM (and other modern JVMs) uses a combination of bytecode interpretation and dynamic compilation. When a class is first loaded, the JVM executes it by interpreting the bytecode. At some point, if a method is run often enough, the dynamic compiler kicks in and converts it to machine code; when compilation completes, it switches from interpretation to direct execution.
• Code may also be decompiled (reverting to interpreted execution) and recompiled for various reasons, such as loading a class that invalidates assumptions made by prior compilations, or gathering sufficient profiling data to decide that a code path should be recompiled with different optimizations.
• One of the challenges of writing good benchmarks (in any language) is that optimizing compilers are adept at spotting and eliminating dead code—code that has no effect on the outcome. Since benchmarks often don’t compute anything, they are an easy target for the optimizer. Most of the time, it is a good thing when the optimizer prunes dead code from a program, but for a benchmark this is a big problem because then you are measuring less execution than you think.
• Many microbenchmarks perform much “better” when run with HotSpot’s -server compiler than with -client, not just because the server compiler can produce more efficient code, but also because it is more adept at optimizing dead code.
• Writing effective performance tests requires tricking the optimizer into not optimizing away your benchmark as dead code. This requires every computed result to be used somehow by your program—in a way that does not require synchronization or substantial computation.
• We happen to need it to verify the correctness of the algorithm, but you can ensure that a value is used by printing it out. However, you should avoid doing I/O while the test is actually running, so as not to distort the run time measurement.
• A cheap trick for preventing a calculation from being optimized away without introducing too much overhead is to compute the hashCode of the field of some derived object, compare it to an arbitrary value such as the current value of System. nanoTime, and print a useless and ignorable message if they happen to match:

  if(foo.x.hashCode()==System.nanoTime())
    System.out.println(" ");
  

  The comparison will rarely succeed, and if it does, its only effect will be to insert a harmless space character into the output. (The print method buffers output until println is called, so in the rare case that hashCode and System.nanoTime are equal no I/O is actually performed.)

• Not only should every computed result be used, but results should also be unguessable. Otherwise, a smart dynamic optimizing compiler is allowed to replace actions with precomputed results.

Java GC

Java’s GC considers objects “garbage” if they aren’t reachable through a chain starting at a garbage collection root, so these objects will be collected. Even though objects may point to each other to form a cycle, they’re still garbage if they’re cut off from the root.

See the section on unreachable objects in Appendix A: The Truth About Garbage Collection in Java Platform Performance: Strategies and Tactics (free ebook, also available on Safari) for the gory details.

Java Garbage collector handles circular-reference!

How?

There are special objects called called garbage-collection roots (GC roots). These are always reachable and so is any object that has them at its own root.

A simple Java application has the following GC roots:

Local variables in the main method
The main thread
Static variables of the main class

To determine which objects are no longer in use, the JVM intermittently runs what is very aptly called a mark-and-sweep algorithm. It works as follows

The algorithm traverses all object references, starting with the GC roots, and marks every object found as alive.
All of the heap memory that is not occupied by marked objects is reclaimed. It is simply marked as free, essentially swept free of unused objects.

So if any object is not reachable from the GC roots(even if it is self-referenced or cyclic-referenced) it will be subjected to garbage collection. Ofcourse sometimes this may led to memory leak if programmer forgets to dereference an object.

The actual answer to this is implementation dependent. The Sun JVM keeps track of some set of root objects (threads and the like), and when it needs to do a garbage collection, traces out which objects are reachable from those and saves them, discarding the rest. It’s actually more complicated than that to allow for some optimizations, but that is the basic principle. This version does not care about circular references: as long as no live object holds a reference to a dead one, it can be GCed.

Other JVMs can use a method known as reference counting. When a reference is created to the object, some counter is incremented, and when the reference goes out of scope, the counter is decremented. If the counter reaches zero, the object is finalized and garbage collected. This version, however, does allow for the possibility of circular references that would never be garbage collected. As a safeguard, many such JVMs include a backup method to determine which objects actually are dead which it runs periodically to resolve self-references and defrag the heap.

A garbage collector starts from some “root” set of places that are always considered “reachable”, such as the CPU registers, stack, and global variables. It works by finding any pointers in those areas, and recursively finding everything they point at. Once it’s found all that, everything else is garbage.

There are, of course, quite a few variations, mostly for the sake of speed. For example, most modern garbage collectors are “generational”, meaning that they divide objects into generations, and as an object gets older, the garbage collector goes longer and longer between times that it tries to figure out whether that object is still valid or not – it just starts to assume that if it has lived a long time, chances are pretty good that it’ll continue to live even longer.

Nonetheless, the basic idea remains the same: it’s all based on starting from some root set of things that it takes for granted could still be used, and then chasing all the pointers to find what else could be in use.

Interesting aside: may people are often surprised by the degree of similarity between this part of a garbage collector and code for marshaling objects for things like remote procedure calls. In each case, you’re starting from some root set of objects, and chasing pointers to find all the other objects those refer to…

How Garbage Collection Really Works

Many people think garbage collection collects and discards dead objects. In reality, Java garbage collection is doing the opposite! Live objects are tracked and everything else designated garbage. As you’ll see, this fundamental misunderstanding can lead to many performance problems.

Garbage-Collection Roots—The Source of All Object Trees

Every object tree must have one or more root objects. As long as the application can reach those roots, the whole tree is reachable. But when are those root objects considered reachable? Special objects called garbage-collection roots (GC roots; see Figure 2.2) are always reachable and so is any object that has a garbage-collection root at its own root.

There are four kinds of GC roots in Java:

1. Local variables are kept alive by the stack of a thread. This is not a real object virtual reference and thus is not visible. For all intents and purposes, local variables are GC roots.
2. Active Java threads are always considered live objects and are therefore GC roots. This is especially important for thread local variables.
3. Static variables are referenced by their classes. This fact makes them de facto GC roots. Classes themselves can be garbage-collected, which would remove all referenced static variables. This is of special importance when we use application servers, OSGi containers or class loaders in general. We will discuss the related problems in the Problem Patterns section.
4. JNI References are Java objects that the native code has created as part of a JNI call. Objects thus created are treated specially because the JVM does not know if it is being referenced by the native code or not. Such objects represent a very special form of GC root, which we will examine in more detail in the Problem Patterns section below.

Therefore, a simple Java application has the following GC roots:

• Local variables in the main method
• The main thread
• Static variables of the main class

Marking and Sweeping Away Garbage

To determine which objects are no longer in use, the JVM intermittently runs what is very aptly called a mark-and-sweep algorithm. As you might intuit, it’s a straightforward, two-step process:

1. The algorithm traverses all object references, starting with the GC roots, and marks every object found as alive.
2. All of the heap memory that is not occupied by marked objects is reclaimed. It is simply marked as free, essentially swept free of unused objects.

Garbage collectors which rely solely on reference counting are generally vulnerable to failing to collection self-referential structures such as this. These GCs rely on a count of the number of references to the object in order to calculate whether a given object is reachable.

Non-reference counting approaches apply a more comprehensive reachability test to determine whether an object is eligible to be collected. These systems define an object (or set of objects) which are always assumed to be reachable. Any object for which references are available from this object graph is considered ineligible for collection. Any object not directly accessible from this object is not. Thus, cycles do not end up affecting reachability, and can be collected.

Tracing collector vs. countering collector

There are two primary types of garbage collectors, although often a hybrid approach is found between these to suit particular needs. The first type, the one which might be the most intuitive, is a reference counting collector. The second one, which is most similar to what we described above, is a tracing collector.

Reference Counting Collector

When a new memory object is allocated by the GC, it is given an integer count field. Every time a pointer is made to that object, a reference, the count is increased. So long as the count is a positive non-zero integer, the object is actively being referenced and is still alive. When a reference to the object is removed, the count is decremented. When the count reaches zero, the object is dead and can be immediately reclaimed. There are a number of points to remember about Reference Counting collectors:

1. Circular references will never be reclaimed, even if the entire set of objects is dead.
2. Reference counting is pervasive: The entire program must be made aware of the system, and every pointer reference or dereference must be accompanied by an appropriate increment or decrement. Failing to maintain the count, even once in a large program, will create memory problems for your program.
3. Reference counting can be costly, because counts must be manipulated for every pointer operation, and the count must be tested against zero on ever decrement. These operations can, if used often enough, create a performance penalty for your program.

These types of collectors are often called cooperative collectors because they require cooperation from the rest of the system to maintain the counts.

Tracing Collector

Tracing collectors are entirely dissimilar from reference counting collectors, and have opposite strengths and weaknesses. When the Tracing GC allocates a new memory chunk, the GC does not create a counter, but it does create a flag to determine when the item has been marked, and a pointer to the object that the GC keeps. The flags are not manipulated by the program itself, but are only manipulated by the GC when it performs a run.

During a GC run, the program execution typically halts. This can cause intermittent pauses in the program, pauses which can be quite long if there are many memory objects to trace.

The GC selects a set of root objects which are available to the current program scope and parent scopes. Starting from these objects, the GC identifies all pointers within the objects, called children. The object itself is marked as being alive, and then the collector moves to each child and marks it in the same way. The memory objects form a sort of tree structure, and the GC traverses this tree using recursive or stack-based methods.

At the end of the GC run, when there are no more children to be marked, all unmarked objects are considered unreachable and therefore dead. All dead objects are collected.

A few points to remember about Tracing GCs:

1. Tracing GCs can be used to find cycles, memory objects whose pointers form circular structures. Reference Counting schemes cannot do this.
2. Tracing GCs cause pauses in the program, and these pauses can become unbearably long in some complex programs that use many small memory objects.
3. Dead objects are not reclaimed immediately. Reclamation only occurs after a GC run. This causes a certain inefficiency in memory usage.
4. Tracing collectors do not require the program to account explicitly for memory counts or memory status updates. All memory tracking logic is stored inside the GC itself. This makes it easier to write extensions for these systems, and also makes it easier to install a Tracing GC in an existing system then to install a Reference Counting one.

Tracing GCs are often called uncooperative collectors because they do not require cooperation from the rest of the system to function properly. Hybrid Collectors

Sometimes, reference counting schemes will utilize Tracing systems to find cyclical garbage. Tracing systems may employ reference counts on very large objects to ensure they are reclaimed quickly. These are just two examples of hybridized garbage collectors that are more common then either of the two “pure” types described above.

In later chapters, we will discuss garbage collectors and their algorithms in more detail.

Java runtime data area

There are 5 areas

1. Heap
2. Java Stack
3. Method Area
4. Native method area
5. PC/Register

Java GC

Java’s GC considers objects “garbage” if they aren’t reachable through a chain starting at a garbage collection root, so these objects will be collected. Even though objects may point to each other to form a cycle, they’re still garbage if they’re cut off from the root.

See the section on unreachable objects in Appendix A: The Truth About Garbage Collection in Java Platform Performance: Strategies and Tactics (free ebook, also available on Safari) for the gory details.

Java Garbage collector handles circular-reference!

How?

There are special objects called called garbage-collection roots (GC roots). These are always reachable and so is any object that has them at its own root.

A simple Java application has the following GC roots:

Local variables in the main method
The main thread
Static variables of the main class

To determine which objects are no longer in use, the JVM intermittently runs what is very aptly called a mark-and-sweep algorithm. It works as follows

The algorithm traverses all object references, starting with the GC roots, and marks every object found as alive.
All of the heap memory that is not occupied by marked objects is reclaimed. It is simply marked as free, essentially swept free of unused objects.

So if any object is not reachable from the GC roots(even if it is self-referenced or cyclic-referenced) it will be subjected to garbage collection. Ofcourse sometimes this may led to memory leak if programmer forgets to dereference an object.

The actual answer to this is implementation dependent. The Sun JVM keeps track of some set of root objects (threads and the like), and when it needs to do a garbage collection, traces out which objects are reachable from those and saves them, discarding the rest. It’s actually more complicated than that to allow for some optimizations, but that is the basic principle. This version does not care about circular references: as long as no live object holds a reference to a dead one, it can be GCed.

Other JVMs can use a method known as reference counting. When a reference is created to the object, some counter is incremented, and when the reference goes out of scope, the counter is decremented. If the counter reaches zero, the object is finalized and garbage collected. This version, however, does allow for the possibility of circular references that would never be garbage collected. As a safeguard, many such JVMs include a backup method to determine which objects actually are dead which it runs periodically to resolve self-references and defrag the heap.

A garbage collector starts from some “root” set of places that are always considered “reachable”, such as the CPU registers, stack, and global variables. It works by finding any pointers in those areas, and recursively finding everything they point at. Once it’s found all that, everything else is garbage.

There are, of course, quite a few variations, mostly for the sake of speed. For example, most modern garbage collectors are “generational”, meaning that they divide objects into generations, and as an object gets older, the garbage collector goes longer and longer between times that it tries to figure out whether that object is still valid or not – it just starts to assume that if it has lived a long time, chances are pretty good that it’ll continue to live even longer.

Nonetheless, the basic idea remains the same: it’s all based on starting from some root set of things that it takes for granted could still be used, and then chasing all the pointers to find what else could be in use.

Interesting aside: may people are often surprised by the degree of similarity between this part of a garbage collector and code for marshaling objects for things like remote procedure calls. In each case, you’re starting from some root set of objects, and chasing pointers to find all the other objects those refer to…

How Garbage Collection Really Works

Many people think garbage collection collects and discards dead objects. In reality, Java garbage collection is doing the opposite! Live objects are tracked and everything else designated garbage. As you’ll see, this fundamental misunderstanding can lead to many performance problems.

Garbage-Collection Roots—The Source of All Object Trees

Every object tree must have one or more root objects. As long as the application can reach those roots, the whole tree is reachable. But when are those root objects considered reachable? Special objects called garbage-collection roots (GC roots; see Figure 2.2) are always reachable and so is any object that has a garbage-collection root at its own root.

There are four kinds of GC roots in Java:

1. Local variables are kept alive by the stack of a thread. This is not a real object virtual reference and thus is not visible. For all intents and purposes, local variables are GC roots.
2. Active Java threads are always considered live objects and are therefore GC roots. This is especially important for thread local variables.
3. Static variables are referenced by their classes. This fact makes them de facto GC roots. Classes themselves can be garbage-collected, which would remove all referenced static variables. This is of special importance when we use application servers, OSGi containers or class loaders in general. We will discuss the related problems in the Problem Patterns section.
4. JNI References are Java objects that the native code has created as part of a JNI call. Objects thus created are treated specially because the JVM does not know if it is being referenced by the native code or not. Such objects represent a very special form of GC root, which we will examine in more detail in the Problem Patterns section below.

Therefore, a simple Java application has the following GC roots:

• Local variables in the main method
• The main thread
• Static variables of the main class

Marking and Sweeping Away Garbage

To determine which objects are no longer in use, the JVM intermittently runs what is very aptly called a mark-and-sweep algorithm. As you might intuit, it’s a straightforward, two-step process:

1. The algorithm traverses all object references, starting with the GC roots, and marks every object found as alive.
2. All of the heap memory that is not occupied by marked objects is reclaimed. It is simply marked as free, essentially swept free of unused objects.

Garbage collectors which rely solely on reference counting are generally vulnerable to failing to collection self-referential structures such as this. These GCs rely on a count of the number of references to the object in order to calculate whether a given object is reachable.

Non-reference counting approaches apply a more comprehensive reachability test to determine whether an object is eligible to be collected. These systems define an object (or set of objects) which are always assumed to be reachable. Any object for which references are available from this object graph is considered ineligible for collection. Any object not directly accessible from this object is not. Thus, cycles do not end up affecting reachability, and can be collected.

Tracing collector vs. countering collector

There are two primary types of garbage collectors, although often a hybrid approach is found between these to suit particular needs. The first type, the one which might be the most intuitive, is a reference counting collector. The second one, which is most similar to what we described above, is a tracing collector.

Reference Counting Collector

When a new memory object is allocated by the GC, it is given an integer count field. Every time a pointer is made to that object, a reference, the count is increased. So long as the count is a positive non-zero integer, the object is actively being referenced and is still alive. When a reference to the object is removed, the count is decremented. When the count reaches zero, the object is dead and can be immediately reclaimed. There are a number of points to remember about Reference Counting collectors:

1. Circular references will never be reclaimed, even if the entire set of objects is dead.
2. Reference counting is pervasive: The entire program must be made aware of the system, and every pointer reference or dereference must be accompanied by an appropriate increment or decrement. Failing to maintain the count, even once in a large program, will create memory problems for your program.
3. Reference counting can be costly, because counts must be manipulated for every pointer operation, and the count must be tested against zero on ever decrement. These operations can, if used often enough, create a performance penalty for your program.

These types of collectors are often called cooperative collectors because they require cooperation from the rest of the system to maintain the counts.

Tracing Collector

Tracing collectors are entirely dissimilar from reference counting collectors, and have opposite strengths and weaknesses. When the Tracing GC allocates a new memory chunk, the GC does not create a counter, but it does create a flag to determine when the item has been marked, and a pointer to the object that the GC keeps. The flags are not manipulated by the program itself, but are only manipulated by the GC when it performs a run.

During a GC run, the program execution typically halts. This can cause intermittent pauses in the program, pauses which can be quite long if there are many memory objects to trace.

The GC selects a set of root objects which are available to the current program scope and parent scopes. Starting from these objects, the GC identifies all pointers within the objects, called children. The object itself is marked as being alive, and then the collector moves to each child and marks it in the same way. The memory objects form a sort of tree structure, and the GC traverses this tree using recursive or stack-based methods.

At the end of the GC run, when there are no more children to be marked, all unmarked objects are considered unreachable and therefore dead. All dead objects are collected.

A few points to remember about Tracing GCs:

1. Tracing GCs can be used to find cycles, memory objects whose pointers form circular structures. Reference Counting schemes cannot do this.
2. Tracing GCs cause pauses in the program, and these pauses can become unbearably long in some complex programs that use many small memory objects.
3. Dead objects are not reclaimed immediately. Reclamation only occurs after a GC run. This causes a certain inefficiency in memory usage.
4. Tracing collectors do not require the program to account explicitly for memory counts or memory status updates. All memory tracking logic is stored inside the GC itself. This makes it easier to write extensions for these systems, and also makes it easier to install a Tracing GC in an existing system then to install a Reference Counting one.

Tracing GCs are often called uncooperative collectors because they do not require cooperation from the rest of the system to function properly. Hybrid Collectors

Sometimes, reference counting schemes will utilize Tracing systems to find cyclical garbage. Tracing systems may employ reference counts on very large objects to ensure they are reclaimed quickly. These are just two examples of hybridized garbage collectors that are more common then either of the two “pure” types described above.

In later chapters, we will discuss garbage collectors and their algorithms in more detail.

to be callibrated

G1 is a concurrent collector that operates on discrete regions within the heap. Each region (there are by default around 2,048 of them) can belong to either the old or new generation, and the generational regions need not be contiguous. The idea behind having regions in the old generation is that when the concurrent background threads look for unreferenced objects, some regions will contain more garbage than other regions. The actual collection of a region still requires that application threads be stopped, but G1 can focus on the regions that are mostly garbage and only spend a little bit of time emptying those regions. This approach—clearing out only the mostly garbage regions—is what gives G1 its name: Garbage First. That doesn’t apply to the regions in the young generation: during a young GC, the entire young generation is either freed or promoted (to a survivor space or to the old generation). Still, the young generation is defined in terms of regions, in part because it makes resizing the generations much easier if the regions are predefined. G1 has four main operations: A young collection A background, concurrent cycle A mixed collection If necessary, a full GC We’ll look at each of those in turn, starting with the G1 young collection shown in Figure 6-6.

Reference

• http://www.ibm.com/developerworks/java/library/j-jtp10283/
• https://blogs.oracle.com/jonthecollector/entry/our_collectors
• https://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Tracing_garbage_collectors
• http://users.cecs.anu.edu.au/~steveb/pubs/papers/urc-oopsla-2003.pdf
• https://www.dynatrace.com/resources/ebooks/javabook/
• https://en.wikipedia.org/wiki/Tracing_garbage_collection
• https://en.wikibooks.org/wiki/Memory_Management/Garbage_Collection
• http://flyingfrogblog.blogspot.com/2013/09/how-do-reference-counting-and-tracing.html
• https://www.dynatrace.com/resources/ebooks/javabook/how-garbage-collection-works/
• http://stackoverflow.com/questions/1910194/how-does-java-garbage-collection-work-with-circular-references
• http://www.java-books.us/j2ee_0003.php
• http://www.ibm.com/developerworks/java/library/j-jtp10283/
• https://blogs.oracle.com/jonthecollector/entry/our_collectors
• https://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Tracing_garbage_collectors
• http://users.cecs.anu.edu.au/~steveb/pubs/papers/urc-oopsla-2003.pdf
• https://www.dynatrace.com/resources/ebooks/javabook/
• https://en.wikipedia.org/wiki/Tracing_garbage_collection
• https://en.wikibooks.org/wiki/Memory_Management/Garbage_Collection
• http://flyingfrogblog.blogspot.com/2013/09/how-do-reference-counting-and-tracing.html
• https://www.dynatrace.com/resources/ebooks/javabook/how-garbage-collection-works/
• http://stackoverflow.com/questions/1910194/how-does-java-garbage-collection-work-with-circular-references
• http://www.java-books.us/j2ee_0003.php

• 2024 15
• 2023 101
• 2022 53
• 2021 19
• 2020 25
• 2019 7
• 2018 39
• 2017 38
• 2016 50