Java JVM Garbage collection mechanism

Before the Java language comes out, everyone is desperately writing C or C + + programs, and there is a great contradiction, C + + and other languages to create objects to continue to open up space, do not need to constantly release the control, not only write the constructor, but also write the destructor, A lot of times are repeated in the allocated, and then constantly ~ destruction. So, someone suggested, can write a program in the implementation of this function, each time the creation, release the control of the time to reuse this code, without repeating the writing?

1960 based on the MIT Lisp first put forward the concept of garbage collection, used to deal with C language and other non-stop destruction operations, and then Java is not born yet! So in fact the GC is not a Java patent, the history of GC is much larger than the history of Java!

So what exactly did the GC do for us?

1. What memory needs to be recycled?

2. When to recycle?

3, how to recycle?

At this time someone will be puzzled, since the GC has solved this contradiction for us, we still need to learn GC? Sure, of course, but when exactly do we need to use it?

1. Troubleshooting Memory Overflow

2. Troubleshooting memory leaks

3. Performance tuning, troubleshooting concurrency bottlenecks

We know that the GC primarily deals with object recycling, so when does it trigger the recycling of an object?

1. Object not referenced

2. An uncaught exception occurred at the scope

3, the program in the scope of normal execution completed

4, the program executed System.exit ()

5. Unexpected termination of program (killing process, etc.)

In fact, the easiest thing to think about is that when an object is not referenced, it is marked as a recyclable object, so now there is a problem, is it not that the object is assigned to NULL after it must be marked as a recyclable object? Let's look at an example:

Package com.yhj.jvm.gc.objEscape.finalizeEscape;

Import Com.yhj.jvm.gc.objEscape.pojo.FinalizedEscapeTestCase;

/**

* @Described: Escape analysis Test

* @author yhj create at 2011-12-24 05:08:09

* @FileNmae Com.yhj.jvm.gc.finalizeEscape.FinalizedEscape.java

*/

public class Finalizedescape {

public static void Main (string[] args) throwsinterruptedexception {

System.out.println (Finalizedescapetestcase.caseforescape);

Finalizedescapetestcase.caseforescape=newfinalizedescapetestcase ();

System.out.println (Finalizedescapetestcase.caseforescape);

Finalizedescapetestcase.caseforescape=null;

System.GC ();

Thread.Sleep (100);

System.out.println (Finalizedescapetestcase.caseforescape);

}

}

Package Com.yhj.jvm.gc.objEscape.pojo;

/**

* @Described: Escape analysis test case

* @author yhj create at 2011-12-24 05:07:05

* @FileNmae Com.yhj.jvm.gc.pojo.TestCaseForEscape.java

*/

public class Finalizedescapetestcase {

public static finalizedescapetestcase caseforescape = null;

@Override

protected void Finalize () throws Throwable {

Super.finalize ();

System.out.println ("Haha, I have escaped!" ");

Caseforescape = this;

}

}

What does the program run as a result of what it looks like?

Let's take a look at this piece of code

1, System.out.println (Finalizedescapetestcase.caseforescape);

2, Finalizedescapetestcase.caseforescape = Newfinalizedescapetestcase ();

3, System.out.println (Finalizedescapetestcase.caseforescape);

4, Finalizedescapetestcase.caseforescape=null;

5, System.GC ();

6, Thread.Sleep (100);

7, System.out.println (Finalizedescapetestcase.caseforescape);

1, when the program executes the first line is, because this object has no value, the result is definitely null

2. The second line of the program assigns the object to a newly opened object

3, the third line when printing, it must be the second line of the object's hash code

4. Row fourth resets the object to null

5, five line trigger GC

6, in order to ensure that the GC can execute successfully, the sixth line waits 100 milliseconds

7, the seventh line to print the corresponding value, return to null? Must it be null?

Let's take a look at the corresponding running results

This example prints the

GC Log, let us see a little more clearly, we clearly see that the last sentence printed is not NULL, and before the son Ah, there has been the escape of the word. It means that the object escaped and escaped before garbage collection, and we'll look at the Pojo, and we'll see that we rewrite the method finalize, which is equivalent to the Destructor method in C + +, which is called once before GC is recycled. This method also points the this pointer to himself, so it can escape successfully! It can be seen that the object is not assigned to NULL after it must be marked as recyclable, it is possible to escape!

Let's take a look at several garbage collection algorithms

1, before the JDK1.2, using the reference counter algorithm, that is, when the class is loaded into memory, will generate a method area, stack, program counter and other information, when the object is created, for this object in the stack space to allocate objects, but also generate a reference counter, and reference counter + 1, when there is a new reference, the reference counter continues +1, and when one of the references is destroyed, the reference counter-1, when the reference counter is reduced to zero, marking the object has no references, can be recycled! This algorithm was widely used in versions prior to JDK1.2, but with the development of the business, a problem soon arose.

When our code is in the following scenario, the algorithm will not be able to accommodate

a) Obja.obj = OBJB

b) Objb.obj-obja

This code produces the following reference case Obja points to objb, and objb points to obja, so that when all other references are gone, Obja and OBJB have a mutual reference, which means that the reference counter for two objects is 1, In fact, both of these objects have no additional references and are already garbage.

2. Root Search algorithm

The root search algorithm is introduced from the graph theory of discrete mathematics, the program regards all referential relationships as a graph, starts with a node GC root, looks for the corresponding reference node, finds the node, and continues to look for the node's reference node, after all the reference nodes have been searched, The remaining nodes are considered nodes that are not referenced, that is, useless nodes.

Currently, the object in Java that can be used as the GC root is

1. Objects referenced in the virtual machine stack (local variable table)

2. Objects referenced by static properties in the method area

3. Objects referenced by constants in the method area

4. Objects referenced in the local method stack (native objects)

Having said so much, we can actually see that all garbage collection mechanisms are related to references, so let's take a concrete look at what types of references are referenced. What do each of these references do?

There are four types of references in Java, each of which is as follows:

1. Strong references

The garbage collector will never recycle as long as the reference exists

Object obj = new Object ();

The corresponding object, such as Obj.equels (new object), can be obtained directly from obj.

And so the Obj object is a strong reference to the later new object, and the object will be freed only if obj is released, which is also the encoding that we often use.

2. Soft reference

Non-mandatory references, which are recycled before memory overflows, can be implemented with the following code

Object obj = new Object ();

softreference<object> SF = new softreference<object> (obj);

obj = null;

Sf.get ();//sometimes returns null

In this case, SF is a soft reference to obj, which can be retrieved through the Sf.get () method, which, of course, returns NULL when the object is marked as an object that needs to be recycled;

Soft reference the main user to implement a similar caching function, in memory enough to directly through the soft reference value, no need to query data from the busy real source, improve speed, when the memory is low, automatically delete this part of the cached data, from the real source to query the data.

3. Weak references

The second garbage collection is recycled and can be implemented with the following code

Object obj = new Object ();

weakreference<object> wf = new weakreference<object> (obj);

obj = null;

Wf.get ();//sometimes returns null

Wf.isenqueued ();//Returns whether the garbage collector is marked as garbage that is about to be recycled

The weak reference is reclaimed at the second garbage collection, the corresponding data is taken from the weak reference in a short time, and null is returned when a second garbage collection is performed.

Weak references are primarily used to monitor whether an object has been marked as garbage collected by the garbage collector, and can be returned by a weakly referenced isenqueued method to the garbage collector

4. Virtual Reference (Phantom/Phantom Reference)

Garbage collection is recycled and cannot be referenced to object values, and can be implemented with the following code

Object obj = new Object ();

Phantomreference<object> PF = new phantomreference<object> (obj);

Obj=null;

Pf.get ();//always returns null

Pf.isenqueued ();//return from memory has been removed

Virtual references are reclaimed every time garbage collection is made, and the data that is obtained by a virtual reference to the Get method is null and therefore is also a ghost reference.

Virtual references are primarily used to detect whether an object has been removed from memory.

As already mentioned, our objects are divided into 5 areas in memory, and the percentage of each piece of data is different, according to IBM statistics, as shown in the data:

We know that the method area primarily stores data about the relationship between classes and classes, and that this part of the data is loaded into memory and is basically not changed.

The data in the Java heap is basically going to die, and we need to recycle it immediately, and the Java stack and the local method stack of data, because there is the principle of LIFO, when I take the following data, must be the stack top elements out of the stack, so the recovery can be considered as 100% And the program counter we have mentioned earlier that the primary user records some information, such as the line number executed by the thread, which is also considered to be the only area that does not have a memory overflow. In the Sunhostspot virtual machine, for the program counter is not recycled, and the method area of data because the recovery is very small, and the cost is relatively high, is generally considered to be "cost-effective" very poor, so Sun's own virtual machine hotspot is not recycled! But in today's high-performance distributed Java EE system, we use a lot of reflection, dynamic Proxy, CGLIB, JSP and OSGi, and so on, these classes frequently call the custom class loader, all need to dynamically load and unload, to ensure that the permanent band does not overflow, they through the custom class loader to do the various operations , so in the actual application development, the class is often loaded and unloaded, the method area will be recycled! However, the recovery condition of the method area is very harsh, and only the following three conditions can be recycled!

1. All instances are recycled

2. ClassLoader to load the class is recycled

3. Class objects cannot be accessed by any means (including reflection)

Well, let's cut to the chase, Java1.2. Before the main use of reference counters to mark the need for garbage collection, and after 1.2 using the root search algorithm to collect garbage, and collected garbage is what algorithm to recycle it?

1. Mark-Sweep algorithm

2. Copy algorithm

3. Marking-Sorting algorithm

Let's have a look

1. Mark-Sweep algorithm

The tag-purge algorithm takes a scan from the root collection, marks the surviving object object, and then scans the entire space for objects that are not tagged, as shown in.

The tag-purge algorithm does not need to move objects, and it only handles objects that are not alive, and is extremely efficient in the case of many surviving objects, but because the tag-purge algorithm directly reclaims the objects that are not alive, it can cause memory fragmentation!

2. Copy algorithm

The replication algorithm takes a scan from the root set and copies the surviving objects into a new, unused space, which is extremely efficient when the control survives the object, but the cost is that a memory swap space is needed for the object to move. That's what we mentioned earlier.

S0 S1 and other space.

3. Marking-Sorting algorithm

Mark

-The collation algorithm uses the tag-sweep algorithm to mark objects in the same way, but when it is cleared, all surviving objects are moved to the left free space after reclaiming the space occupied by the objects that are not alive, and the corresponding pointers are updated. The tag-collation algorithm, which is based on the tag-purge algorithm and moves the object, is more expensive, but solves the problem of memory fragmentation.

We know that the JVM, in order to optimize the recovery of memory, the method of generational recovery, for the new generation of memory recovery (minor GC) mainly uses the replication algorithm, shows the minor GC execution process.

For the Cenozoic and the old generation,

The JVM can use many kinds of garbage collector for garbage collection, showing the different generation of garbage collector, there is a connection between the two of the collector to indicate that the two collector can be used simultaneously.

And these garbage collector is divided into serial recovery method, the parallel recovery method combined with the implementation of the collection, respectively, used in different scenarios. As shown

Let's take a look at each garbage collector.

1. Serial Collector

Look at the name we can all see, this belongs to the serial collector. It runs as follows

Serial

The collector is one of the oldest collectors, JDK1.3 used extensively before, and is currently the default garbage collector for CLIENTVM under SERVERVM 4 cores under 4GB. The serial collector does not have to use only one CPU to collect, but when the JVM needs to be garbage collected, it needs to interrupt all the user threads, know that it is the end of the collection, and therefore known as the "Stop the World" garbage collector. Note that the JVM Chinese name is a Java virtual machine, so it works like a virtual computer, and each of these threads is considered to be a processor of the JVM, so you can see that the CPU0 and CPU1 in the diagram are actually the threads of the user, not the CPU of the real machine, and don't misunderstand.

Serial recycling method is suitable for low-end machine, is the default collector in client mode, the CPU and memory consumption is not high, suitable for user interaction less, background task more system.

The serial collector defaults to the new old generation of the recycler with the serial+ serialold

2. Parnew Collector

The Parnew collector is actually a multithreaded version of the serial collector, which runs as follows

also has

Stop The world problem, he is the preferred collector in multi-CPU mode (the collector in a single CPU environment is much less efficient than the serial collector, so be sure to pay attention to the scene OH) and also the default collectors in server mode.

3, Parallelscavenge

Parallelscavenge is also known as a throughput-first collector that runs as follows

Parallelscavenge

The mentioned throughput = program run time/(the JVM recycles time + program run time), assuming the program is running for 100 minutes and the JVM's garbage collection takes 1 minutes, then throughput is 99%. In today's network to tell the developed world, good response speed is an important indicator to enhance the user experience, multi-core parallel cloud computing development requires the program to use CPU and memory resources as soon as possible to calculate the final results, so in the cloud of less interaction, it is more appropriate to use the collector.

4, Parallelold

Parallelold is a Laosheng-generation parallel collector, using the tag grooming algorithm, which is a collector of laosheng generation throughput precedence. This collector is just introduced after the JDK1.6 of a collector, we look at the correlation between the previous graph can be seen, before the early parallelold, the throughput-first collector Laosheng can only use the serial recycle collector, greatly drag the throughput first performance, since the JDK1.6, can really do more efficient Rate of throughput is preferred. It runs as follows

5.

Serialold

Serialold is the default collector in the old generation client mode, single-threaded execution, and before JDK1.6 is the default collector of the old generation in the Parallelscvenge recovery generation mode, and the standby collector after the failed collection of the concurrent collector CMS. It runs as follows

6.

Cms

CMS is also known as response time first (the shortest recovery pause) of the collector, using the concurrency mode to reclaim garbage, using the tag-purge algorithm, the CMS is very sensitive to the CPU, its number of recycled threads = (cpu+3)/4, so when the CPU is 2 core of the benefits, recycling threads will occupy 50% of the CPU resources, When the CPU core number is 4, it takes only 25%. He's running as follows

Cms

The pattern is divided into 4 main processes

During the initial tag, all user threads need to be interrupted, during the concurrency tagging phase, the user thread and the markup thread

Concurrent execution, and in this process, as the memory reference relationship changes, the original tagged object may be released, causing new garbage, and therefore potentially generating a series of floating garbage that cannot be reclaimed.

CMS in order to ensure that all objects can be scanned, to avoid the initial marking in the non-identified objects, the method is to find the tagged objects, and put these objects in the stack, scan the object dependent on the search for objects, if the dependent object's address before it, The object is marked and placed in the stack, such that the object is only marked after the dependent object address is behind it.

The minor GC may also occur at the same time when the concurrent marking is in progress, which can easily lead to changes in the old generation object reference relationship, and the CMS provides a mod union Table to record in order to deal with such concurrency, in which the MoD union The table records information about the card that was modified after each minor GC. This is also the reason why Parallelscavenge cannot be used with CMS.

If the CMS generates floating garbage, please see the following

After the recycle is run, C becomes a floating garbage.

Because the CMS will produce floating garbage, when recycled, if the floating garbage generated too much, and because the use of the tag-clearing algorithm will be fragmented, may cause the recovery of contiguous space still can not accommodate the new generation of mobile or newly created large resources, it will cause the recovery of the CMS failed, The second full GC is triggered, and at this time the serialold is used for two recoveries.

At the same time, because the CMS can generate floating garbage, while the CMS in the implementation of the recovery of the new generation may also be in the recovery operation, in order to ensure that the old generation can store the new generation of transferred data, CMS in the old generation of memory to reach the full capacity of 68% triggered the recovery of the CMS!

7, Garbagefirst (G1)

Let's look at the general picture of the garbage collector, and just now we can see that I marked one on the chart? , in fact, this is a new garbage collector, can be recycled or can reclaim the old generation, Sunhotspot 1.6u14 above earlyaccess version added this collector, Sun expects SunHotSpot1.7 to release the official version, which is a commercial high-performance garbage collector that, by re-partitioning the memory area, integrates and optimizes the CMS, while focusing on throughput and response time, but the Cup is owned by Oracle after the acquisition of this collector belongs to the commercial charge collector, so currently basically no one uses, we are here Not much more, more information can be found in Oracle's new version of the JDK description.

Now let's look at some of the JVM's memory allocation and recycling policies

1, priority on the allocation of Edon on the object

code example

Package Com.yhj.jvm.gc.edenFirst;

/**

* @Described: Edon First Division Object test

* VM params:-XMS20M-XMX20M-XMN10M-XX:+PRINTGCDETAILS-VERBOSE:GC

* Edon s0 S1 old

* 8 1 1 10

* @author yhj create at 2012-1-3 04:44:43

* @FileNmae Com.yhj.jvm.gc.edenFirst.EdonFirst.java

*/

public class Edonfirst {

Private final static int one_mb = 1024*1024;

/**

* @param args

* @Author yhj create at 2012-1-3 04:44:38

*/

public static void Main (string[] args) {

@SuppressWarnings ("unused")

Byte[] TESTCASE1,TESTCASE2,TESTCASE3,TESTCASE4;

TestCase1 = new BYTE[2*ONE_MB];

TestCase2 = new BYTE[2*ONE_MB];

TESTCASE3 = new BYTE[2*ONE_MB];

TESTCASE1 = null;

TestCase2 = null;

TESTCASE3 = null;

TestCase4 = new BYTE[2*ONE_MB];

}

}

Run results

Results analysis

From the running results we can clearly see that Eden has a 8MB storage control (via parameter configuration), the first 6MB of data is first assigned to the Eden Zone, when the next 2MB storage, because the space is full, triggered a GC, but this part of the data because there is no recycling (the reference is still in, When the assignment is null, it is not transferred), the data is copied to the S0 zone, but the S0 area is not stored enough, so it is placed directly into the Laosheng region and the new 2MB data is stored in the Eden area.

2, large objects directly into the Laosheng generation

code example

Package com.yhj.jvm.gc.bigObjIntoOld;

/**

* @Described: Large object directly into Laosheng generation test

* VM params:-XMS20M-XMX20M-XMN10M-XX:+PRINTGCDETAILS-VERBOSE:GC

* Edon s0 S1 old

* 8 1 1 10

* @author yhj create at 2012-1-3 05:28:47

* @FileNmae Com.yhj.jvm.gc.bigObjIntoOld.BigObjIntoOld.java

*/

public class Bigobjintoold {

Private final static int one_mb = 1024*1024;

/**

* @param args

* @Author yhj create at 2012-1-3 04:44:38

*/

public static void Main (string[] args) {

@SuppressWarnings ("unused")

Byte[] TESTCASE1,TESTCASE2,TESTCASE3,TESTCASE4;

TestCase1 = new BYTE[8*ONE_MB];

TestCase2 = new BYTE[2*ONE_MB];

TESTCASE3 = new BYTE[2*ONE_MB];

TESTCASE1 = null;

TestCase2 = null;

TESTCASE3 = null;

TestCase4 = new BYTE[2*ONE_MB];

}

}

Run results

Results analysis

We see that no GC logs are triggered, and the data is directly into the Laosheng generation

3, Elder (long-term survival target) into the Laosheng generation

code example:

Package com.yhj.jvm.gc.longLifeTimeIntoOld;

/**

* @Described: When the age is greater than a certain value, enter the Laosheng default value of 15 years

* VM params:-XMS20M-XMX20M-XMN10M-XX:MAXTENURINGTHRESHOLD=1-XX:+PRINTGCDETAILS-VERBOSE:GC

* Edon s0 S1 old age

* 8 1 1 10 1

* @author yhj create at 2012-1-3 05:39:16

* @FileNmaecom. Yhj.jvm.gc.longLifeTimeIntoOld.LongLifeTimeIntoOld.java

*/

public class Longlifetimeintoold {

Private final static int one_mb = 1024*1024;

/**

* @param args

* @Author yhj create at 2012-1-3 04:44:38

*/

public static void Main (string[] args) {

@SuppressWarnings ("unused")

Byte[] TESTCASE1,TESTCASE2,TESTCASE3,TESTCASE4;

TestCase1 = new BYTE[1*ONE_MB/4];

TestCase2 = new BYTE[7*ONE_MB+3*ONE_MB/4];

TestCase2 = null;

TESTCASE3 = new BYTE[7*ONE_MB+3*ONE_MB/4];

TESTCASE3 = null;

TestCase4 = new BYTE[ONE_MB];

}

}

Run results

Results analysis

From the code we can see that When TestCase1 is divided into 0.25MB data, after multiple large object creation, TESTCASE1 should be copied to the S0 area after GC execution (S0 enough to hold testCase1), but we set the age of the object to 1, that is, more than 1 years old into the Laosheng generation, so the GC executes 2 times after Testcas E1 is copied directly to the Laosheng generation, and the default entry to Laosheng generation is 15. We can clearly see the age of the object through the Profilter monitoring tool,

The number of years on the right is the age of the object

4, group effect (a large number of middle-aged objects into Laosheng generation)

code example

Package com.yhj.jvm.gc.dynamicMoreAVG_intoOld;

/**

* @Described: S0 occupied space reaches 50% directly into Laosheng generation

* VM params:-XMS20M-XMX20M-XMN10M-XX:MAXTENURINGTHRESHOLD=15-XX:+PRINTGCDETAILS-VERBOSE:GC

* Edon s0 S1 old age

* 8 1 1 10 15

* 0.5 0 0 7.5

* 7.5 0.5 0 7.5

* 7.5 0 0 8

* @author yhj create at 2012-1-3 05:50:40

* @FileNmae Com.yhj.jvm.gc.dynamicMoreAVG_intoOld.MoreAVG_intoOld.java

*/

public class Moreavg_intoold {

Private final static int one_mb = 1024*1024;

/**

* @param args

* @Author yhj create at 2012-1-3 04:44:38

*/

public static void Main (string[] args) {

@SuppressWarnings ("unused")

Byte[] TESTCASE1,TESTCASE2,TESTCASE3,TESTCASE4;

TestCase1 = new BYTE[7*ONE_MB+ONE_MB/2];

TestCase2 = new BYTE[ONE_MB/2];

TESTCASE3 = new BYTE[7*ONE_MB+ONE_MB/2];

TESTCASE3 = null;

TestCase4 = new BYTE[7*ONE_MB+ONE_MB/2];

TestCase1 = new BYTE[7*ONE_MB+3*ONE_MB/4];

TestCase2 = new BYTE[ONE_MB/4];

TESTCASE3 = new BYTE[7*ONE_MB+3*ONE_MB/4];

}

}

Run results

Results analysis

We see that when the Testcase3,testcase2 is moved to the S0 area after it is created, when it is released, it continues to create the TESTCASE3, supposedly testCase2 should be moved to the S1 area, but because it exceeds 1/2 of the S1 area, it goes directly into the Laosheng generation

5. Guarantee GC (Guarantee MINORGC)

Guaranteed GC is the guarantee that MINORGC can meet the current storage space, without triggering the recovery of the Laosheng generation, because most of the objects are going to die, so in real development this is very effective, but there may be a case of guarantee failure, when the guarantee failure will trigger FULLGC, But failure is, after all, a minority, so this is generally a bargain.

code example

Package com.yhj.jvm.gc.securedTransactions;

/**

* @Described: Guaranteed Transaction Testing

* VM params:-xms20m-xmx20m-xmn10m-xx:+printgcdetails-verbose:gc-xx:-handlepromotionfailure no warranty

* VM params:-xms20m-xmx20m-xmn10m-xx:+printgcdetails-verbose:gc-xx:+handlepromotionfailure secured

* Edon s0 S1 old

* 8 1 1 10

* @author yhj create at 2012-1-3 06:11:17

* @FileNmaecom. Yhj.jvm.gc.securedTransactions.SecuredTransactions.java

*/

public class Securedtransactions {

Private final static int one_mb = 1024*1024;

/**

* @param args

* @Author yhj create at 2012-1-3 04:44:38

*/

public static void Main (string[] args) {

@SuppressWarnings ("unused")

Byte[] Testcase1,testcase2,testcase3,testcase4,testcase5,testcase6,testcase7;

TestCase1 = new BYTE[2*ONE_MB];

TestCase2 = new BYTE[2*ONE_MB];

TESTCASE3 = new BYTE[2*ONE_MB];

TESTCASE1 = null;

TestCase4 = new BYTE[2*ONE_MB];

TESTCASE5 = new BYTE[2*ONE_MB];

TestCase6 = new BYTE[2*ONE_MB];

TESTCASE4 = null;

TESTCASE5 = null;

TestCase6 = null;

TestCase7 = new BYTE[2*ONE_MB];

}

}

Run results

1. No warranty

2.

With warranty

Results analysis

We can clearly see that when there is no guarantee, when a FULLGC is triggered and secured, only the MONORGC completes the recovery, greatly improving the efficiency.

When we comment out the corresponding code

TESTCASE4 = null;

TESTCASE5 = null;

TestCase6 = null;

Will trigger a warranty failure, as shown in

Jvm

The default is to turn on the warranty without setting parameters.

• Size: 89.7 KB

• Size: 20.3 KB

• Size: 40.7 KB

• Size: 47.6 KB

• Size: 26.7 KB

• Size: 17.2 KB

• Size: 33.6 KB

• Size: 47.3 KB

• Size: 55.4 KB

• Size: 21.8 KB

• Size: 18.6 KB

• Size: 20.5 KB

• Size: 45.2 KB

• Size: 18.5 KB

• Size: 20.6 KB

• Size: 23.5 KB

• Size: 46.1 KB

• Size: 69.7 KB

• Size: 53.5 KB

• Size: 64.2 KB

• Size: KB

• Size: 71.7 KB

• Size: 42.7 KB

• Size: 64.7 KB

• Size: 60.4 KB

• Size: 21.3 KB

Java JVM garbage collection mechanism