Erlang process heap garbage collection mechanism

Http://blog.csdn.net/mycwq

Each Erlang process will have its own PCB, stack, and private heap after it is created. Erlang does not know which situation the process he creates will be used, so the memory allocated at the beginning is relatively small. If there is not enough space allocated, Erlang GC dynamically adjusts the heap size to meet demand, and if the allocated space is large, it shrinks the heap and reclaims the memory.

The GC for the Erlang process heap is a generational GC, and the idea of generational GC is based on statistics: most of the data has a shorter life cycle and the latest data is easier to use. This is where Erlang uses the young heap and the old heap to differentiate the data, and the new data is released from the oldest heap, which is the data that survived after the GC.

The Erlang process heap GC has two main processes: Shallow scan and deep scan

Light Scan (minor collection)

A shallow scan is when the young heap is running out of space, Erlang will do a scan of the old heap, copy the useful data into the new application's space, discover that the data has been scanned more than 1 times into the older heap, and then delete the original heap

In the young heap, Erlang uses a high watermark to distinguish between more than one mark of data and unlabeled data, and then the young heap moves into the old heap beyond the high watermark data

deep Scan (major collection)

Deep scan is usually triggered when the old heap is out of space, Erlang scans the young heap and the new heap, and puts the useful data into the newly applied, deleted heap

Deep scan trigger conditions also have manual GC, and the number of GC times exceeds fullsweep_after parameter qualification

Controlling garbage collection

In the game gateway process, for example, the gateway process usually has a lot of messages, and most of the messages are just forwarded here in the gateway, the life cycle is very short, so the gateway process can set a large initial memory, faster memory recovery.

spawn_opt (fun, [{min_heap_size, 5000},{min_bin_vheap_size, 100000},{fullsweep_after, and])

First look at the default values of the parameters:
1> Erlang:system_info (min_heap_size).
{min_heap_size,233}
2> Erlang:system_info (min_bin_vheap_size).
{min_bin_vheap_size,46368}
3> Erlang:system_info (fullsweep_after).
{fullsweep_after,65535}

Min_heap_size is the process minimum heap size

This parameter is used in two places, the first is the Erlang initialization process heap size, the second is the minimum value maintained after the heap shrinks after the GC, and the min_bin_vheap_size is the process minimum virtual binary heap size, both of which are in Word. Initialize large enough initial memory to reduce the number of light GC cycles and reduce the overhead of repeatedly requesting and recovering memory

Fullsweep_after controlling the frequency of deep scanning

This parameter determines how many times the GC executes once in depth GC, the default value is 65536, a little bit larger

So, the meaning of the above 3 parameters is that the process is initialized to allocate large enough memory, reduce the cost of repeated requests for memory, when the requested memory is not enough, the GC will re-request memory, accumulated 500 times to do GC

manually perform garbage collection

The above mentioned the use of Fullsweep_after to control GC, the following is the case of manual GC:
In the RABBITMQ see this code, you can periodically execute this function in your project:
GC (),
[Erlang:garbage_collect (P) | | P <-erlang:processes (),
{status, waiting} = = Erlang:process_info (P, status)],
Erlang:garbage_collect (),
Ok.
Of course, you can also add some judgments, such as specifying a process that takes up over 50M of memory to perform GC

How much memory is consumed by the Erlang process

Use this method to check the memory occupied by the Erlang process, you can change the parameters and try again
Fun = Fun (), receive after infinity, OK end end.
Erlang:process_info (Erlang:spawn (fun), memory).

side effects of Erlang garbage collection

The GC in front of the Erlang process heap is a generational GC, and this is a global level, and in the bottom Erlang it is the path to the tag cleanup. Flag Cleanup This GC method is performed on a regular basis, first the GC is not timely enough, and secondly, the overhead during GC execution is relatively large, which can cause interruptions. However, the heap area of each Erlang process is independent, the GC can be done independently, the memory area is small, and Erlang's variable is a single assignment, without multiple tracking, so the latency of the Erlang process GC does not cause global disruption

Erlang Documentation Reference
GC in Erlang works independently on each erlang process, i.e. each Erlang process have its own heap, and the heap is GCed Independently of other processes ' heaps.
The current default GC was a "Stop the world" generational mark-sweep collector. On Erlang systems running with multiple threads (the default in systems with more than one core), GC stops work on the ERL Ang process being GCed, but other Erlang processes on other OS threads within the same VMS continue to run. The time the process spends stopped is normally short because the size of one process ' heap is normally relatively small; Much smaller than the combined size of all processes heaps.

Concluding remarks

Here is the Erlang process heap GC, and Erlang has other GC mechanisms, such as the binary shared heap and the out-of-process heap fragment is the reference count GC, here is not a discussion, there is time I will be in the next article to discuss, interested can see here to understand.

Reference:

http://blog.csdn.net/mycwq/article/details/26613275

Http://www.cnblogs.com/me-sa/archive/2011/11/13/erlang0014.html

Erlang process heap garbage collection mechanism