What is a garbage collector for in Java

The Garbage Collector only needs to do two things:

  • Find garbage - unused objects. (An object is considered unused if none of the entities in the code currently executing contains references to it, or the chain of links that could connect the object with some application entity is broken);
  • Free memory from garbage.

There are two approaches to detecting garbage:

  • Reference counting;
  • Tracing

Reference counting. The essence of this approach is that each object has a counter. A counter stores information about how many references are pointing to an object. When the link is destroyed, the counter is decremented. If the counter value is zero, the object can be considered garbage. The main disadvantage of this approach is the difficulty of ensuring the accuracy of the meter. Also, with this approach, it is difficult to detect circular dependencies (when two objects point to each other, but no living object refers to them), which leads to memory leaks.

The main idea of the Tracing approach (tracing) is the assertion that only those objects that we can get to from the root points (GC Root) and those objects that are accessible from the living object can be considered alive. Everything else is rubbish.

There are 4 types of root points:

  • Local variables and method parameters;
  • Streams;
  • Static variables;
  • Links from JNI.

The simplest Java application will have root points:

  • Local variables inside the main() method and parameters of the main() method;
  • The thread that executes main();
  • Static variables of the class inside which the main() method is located.

Thus, if we represent all objects and links between them as a tree, then we will need to go from root nodes (points) along all edges. At the same time, the nodes that we can get to are not garbage, all the rest are garbage. With this approach, cyclical dependencies are easily identified. HotSpot VM takes exactly this approach.

There are two main methods for cleaning up memory from garbage:

  • Copying collectors
  • Mark-and-sweep

With the copying collectors approach, memory is divided into two parts "from-space" and "to-space", while the principle of operation is as follows:

  • Objects are created in "from-space";
  • When the "from-space" is full, the application is suspended;
  • The garbage collector starts. Live objects are found in "from-space" and copied to "to-space";
  • When all objects are copied, "from-space" is completely cleared;
  • "To-space" and "from-space" are swapped.

The main advantage of this approach is that objects are densely clogging up memory. Cons of the approach:

  • The application must be stopped for the time it takes to complete the garbage collection cycle;
  • In the worst case (when all objects are alive) "form-space" and "to-space" will have to be the same size.

The mark-and-sweep algorithm can be described as follows:

  • Objects are created in memory;
  • At the moment when the garbage collector needs to be started, the application is suspended;
  • The collector walks through the object tree, marking live objects;
  • The collector loops through the entire memory, finding all unmarked chunks of memory and storing them in the "free list";
  • When new objects start to be created they are created in memory available in the "free list".

Cons of this method:

  • The application does not run while garbage collection is in progress;
  • The stopping time directly depends on the memory size and the number of objects;
  • If you do not use "compacting" the memory will not be used efficiently.

HotSpot VM garbage collectors use a combined Generational Garbage Collection approach that allows different algorithms to be used for different stages of garbage collection. This approach is based on the fact that:

  • most objects created quickly become garbage;
  • there are few links between objects that were created in the past and newly created objects.

Read also:


Comments

Post a Comment

Popular posts from this blog

Methods for reading XML in Java

Image
DOM (Document Object Model) - object - reads XML, recreating it in memory in the form of an object structure, while the XML document is represented as a set of tags - nodes. Each node can have an unlimited number of child nodes. Each child can also contain several levels of descendants or none at all. Thus, the result is a kind of tree. Pluses: Easy to program. If there are many objects in XML with cross-references to each other, it is enough to go through the document twice: first time create objects without references and fill in the name-object dictionary, the second time - restore links. If an error occurs in XML, a half-created XML structure remains in memory, which will be automatically destroyed. Suitable for both reading and writing. Minuses: Low speed. Wastes a lot of memory. SAX (Simple API for XML) - event-driven - reads an XML document, responding to emerging events (opening or closing tag, string, attribute) by calling the event handlers provided by the appl...
Read more

XML, well-formed XML and valid XML

Image
XML, the eXtensible Markup Language, is a language with a simple formal syntax, well suited for creating and manipulating documents with programs, and at the same time easy to read and create documents by humans. XML is extensible, it does not fix the markup used in documents, and the developer is free to create markup in accordance with the needs of a particular area, being limited only by the syntax rules of the language. DTD A DTD, Document Type Definition, is a predefined set of rules that defines the relationships between elements and attributes. For example, the DTD for HTML says that the DIV tag must be inside the BODY tag and can appear multiple times, TITLE - in HEAD and only once, and SCRIPT - both there and there as many times as you want. A DTD is usually described directly in the document as a formulation line starting with <!DOCTYPE ... > or in a separate file. Difference between well-formed XML and valid XML Depending on the level of compliance, the document...
Read more

ArrayList and LinkedList in Java, memory usage and speed

Image
How much extra memory is needed when calling ArrayList.add()? If there is enough space in the array to accommodate a new element, then no additional memory is required. Otherwise, a new array is created, 1.5 times larger than the existing one (this is true for JDK above 1.7, in earlier versions the size of the increase is different). How much extra memory is allocated when you call LinkedList.add()? One new instance of the nested Node class is created. How much memory to store one byte primitive in LinkedList? Each LinkedList element stores a link to the previous element, the next element, and a data link. private static class Node<E> { E item; Node<E> next; Node<E> prev; //... } For 32-bit systems, each link is 32 bits (4 bytes). The object (header) of the nested Node class itself takes 8 bytes. 4 + 4 + 4 + 8 = 20 bytes, and since the size of each object in Java is a multiple of 8, so we get 24 bytes. A byte primitive occupies 1 by...
Read more