Could somebody please explain me what is generations in garbage collection?
i am reading it on internet but feeling difficult to understand it...
A generation is a group of objects. A generational garbage collector groups objects based upon how many runs of the collector they have survived.
Initially, all object will be in the first generation (a group of objects). Then after the garbage collector runs some of the objects will be collected since no one is referencing them anymore but the rest will be placed is the second generation group.
The objects are grouped into generations to exploit the idea that more recently created objects become unused most often. A generational garbage collector will collect the first generation more often than the second generation, and second more than the third...
Related
I want to know technical details about garbage collection (GC) and memory management in Erlang/OTP.
But, I cannot find on erlang.org and its documents.
I have found some articles online which talk about GC in a very general manner, such as what garbage collection algorithm is used.
To classify things, lets define the memory layout and then talk about how GC works.
Memory Layout
In Erlang, each thread of execution is called a process. Each process has its own memory and that memory layout consists of three parts: Process Control Block, Stack and Heap.
PCB: Process Control Block holds information like process identifier (PID), current status (running, waiting), its registered name, and other such info.
Stack: It is a downward growing memory area which holds incoming and outgoing parameters, return addresses, local variables and temporary spaces for evaluating expressions.
Heap: It is an upward growing memory area which holds process mailbox messages and compound terms. Binary terms which are larger than 64 bytes are NOT stored in process private heap. They are stored in a large Shared Heap which is accessible by all processes.
Garbage Collection
Currently Erlang uses a Generational garbage collection that runs inside each Erlang process private heap independently, and also a Reference Counting garbage collection occurs for global shared heap.
Private Heap GC: It is generational, so divides the heap into two segments: young and old generations. Also there are two strategies for collecting; Generational (Minor) and Fullsweep (Major). The generational GC just collects the young heap, but fullsweep collect both young and old heap.
Shared Heap GC: It is reference counting. Each object in shared heap (Refc) has a counter of references to it held by other objects (ProcBin) which are stored inside private heap of Erlang processes. If an object's reference counter reaches zero, the object has become inaccessible and will be destroyed.
To get more details and performance hints, just look at my article which is the source of the answer: Erlang Garbage Collection Details and Why It Matters
A reference paper for the algorithm: One Pass Real-Time Generational Mark-Sweep Garbage Collection (1995) by Joe Armstrong and Robert Virding in
1995 (at CiteSeerX)
Abstract:
Traditional mark-sweep garbage collection algorithms do not allow reclamation of data until the mark phase of the algorithm has terminated. For the class of languages in which destructive operations are not allowed we can arrange that all pointers in the heap always point backwards towards "older" data. In this paper we present a simple scheme for reclaiming data for such language classes with a single pass mark-sweep collector. We also show how the simple scheme can be modified so that the collection can be done in an incremental manner (making it suitable for real-time collection). Following this we show how the collector can be modified for generational garbage collection, and finally how the scheme can be used for a language with concurrent processes.1
Erlang has a few properties that make GC actually pretty easy.
1 - Every variable is immutable, so a variable can never point to a value that was created after it.
2 - Values are copied between Erlang processes, so the memory referenced in a process is almost always completely isolated.
Both of these (especially the latter) significantly limit the amount of the heap that the GC has to scan during a collection.
Erlang uses a copying GC. During a GC, the process is stopped then the live pointers are copied from the from-space to the to-space. I forget the exact percentages, but the heap will be increased if something like only 25% of the heap can be collected during a collection, and it will be decreased if 75% of the process heap can be collected. A collection is triggered when a process's heap becomes full.
The only exception is when it comes to large values that are sent to another process. These will be copied into a shared space and are reference counted. When a reference to a shared object is collected the count is decreased, when that count is 0 the object is freed. No attempts are made to handle fragmentation in the shared heap.
One interesting consequence of this is, for a shared object, the size of the shared object does not contribute to the calculated size of a process's heap, only the size of the reference does. That means, if you have a lot of large shared objects, your VM could run out of memory before a GC is triggered.
Most if this is taken from the talk Jesper Wilhelmsson gave at EUC2012.
I don't know your background, but apart from the paper already pointed out by jj1bdx you can also give a chance to Jesper Wilhelmsson thesis.
BTW, if you want to monitor memory usage in Erlang to compare it to e.g. C++ you can check out:
Erlang Instrument Module
Erlang OS_MON Application
Hope this helps!
Since Apple introduced automatic reference counting back in 2011, never really thought about it, BUT if you see the ARC algorithm and according to apple documentation all objects gets destroyed after some time.
And if I see the release video from the WWDC 2011 you can see that this is not a garbage collector.
so the question is, if it does uses a garbage collector algorithms and all objects get destroy in the end, why is not a garbage collector?
sorry if this has been ask before, but I'm really confuse about this matters and I need help to understand it well
It's a bit of a philosophical question, but essentially, it's a compile-time garbage collector, as a opposed to a run-time garbage collector.
Instead of a garbage-collecting subsystem that runs together with the program, the manages the retain count and ensures that all the necessary releases and retains are put in the right place.
The practical upshot of this is that because it's done by the compiler, it's less error-prone than manual retain/release, and because it's done at compile-time, it's faster than a garbage collector.
This question should shed further light on the issue.
ARC has absolutely nothing to do with garbage collection algorithms. Automated Reference Counting (ARC) uses reference counting as its underlying mechanism for making decisions about reachability of an object. In contrast, garbage collection algorithms maintain a list of "root" objects (e.g. local variables, static variables, thread objects) and use these roots to traverse object graphs to check for reachability of an object. This process is non-deterministic, in the sense that you never know when the GC algorithm is going to run, and when objects that are no longer referenced would be garbage collected. All you know is that they eventually will be garbage collected, but "eventually" may mean a really long time.
Since GC uses graph traversal for reachability analysis, it does not care about cycles in a graph: if an object is reachable from some set of objects that are not in the root set, it is still considered garbage and would be collected. Therefore, you do not need to worry about retain cycles - a very real problem that you need to always keep in mind when working with reference counting systems.
Reference counting is much simpler than garbage collection: each object has a reference count shown in the diagram, retain increments it, and release decrements it. Once the count gets to zero, the object gets destroyed. That's really it! All that ARC does is automating the insertion of calls to retain and release. In fact, it is not possible to tell from this diagram alone if we are talking about the new ARC, or a pre-ARC memory management of Cocoa. Under a reference counting system you know exactly when your object is going to be released - it is going to happen as soon as its reference count reaches zero. Autoreleasing makes this a little less visible to you, because the last reference may be released outside of your code, but that does not make the process non-deterministic. Moreover, the language lets you take full control over autoreleasing by letting you make your own autorelease pools.
I want to add that a GC typically reviews the whole object graph to find unreachable objects in circular references. In ARC – it is still RC – only the relationships of a object being dealloc'd are reviewed. If you have a circular reference, this will never be done, the participating objects will never be dealloc'd.
Apparently I can't give an answer to comments yet (new account). However, what #daskblinkenlight describes is exactly what the the book Programming Language Concepts by Peter Sestoft defines as Garbage Collection by Reference Counting (Page 179). I don't really see the difference.
Moreover, I wrote an email to Peter Sestoft (Professor at ITU Copenhagen) asking him if ARC is a garbage collection and he gave the following answer (translated from danish):
"In my opinion (and for instance Paul Wilsons survey "Uniprocessor garbage collection techniques") ARC is definitely a garbage collector."
i'm using WMI SMBios to get some hardware information
check uSMBios.pas
i don't wanna users see what is the used serial numbers in memory so i'm trying to clear it
when i call
SMBios:=TSMBios.Create;
//my code
SMBios.free;
the SMBios Object still in memory in many locations
i tried this code on Destroy Event
if Assigned(FRawSMBIOSData.SMBIOSTableData) then
begin
ZeroMemory(FRawSMBIOSData.SMBIOSTableData,FRawSMBIOSData.Length);
FreeMem(FRawSMBIOSData.SMBIOSTableData);
end;
it working great with GetSystemFirmwareTable API code in SMBios but in WMI it removes some memory but still i can find few blocks
wondering why after calling object.free or freeandnil the used memory not released
any idea how to force the application to free it ?
Memory is released, it is just not wiped. You maybe mistake two concepts: the memory is bound to some owner and cannot be given to another one, and memory is cleansed of all the information.
Look, when you go over fresh snow or over sands, you leave your footsteps behind you. You moved away, so the places you've been through are FREE now for anyone else to occupy. But your footsteps remain there until someone would overwrite them with his own ones.
Now, you may be paranoid and after every step you would turn back, take a brush and remove your fresh footstep. That is possible and might make sense, but it might be painfully slow.
Some objects might deal with sensitive data, like passwords, cipher keys, personal data in mass calculations, etc. For those objects there is the sense to be paranoid and brush out every their trace. So those objects are written in a way to wipe the memory they would no more need immediately after last use. And to do it once again in the destructor.
But when you just closed the form with the message like "file saved successfully" there ain't any secrets worth painting over. And that is the most of the program.
So now please decide if you really have some sensitive data like passwords. If you do - your code should overwrite it with different data before freeing. And you would have to learn how the data is kept for different types in Delphi, so pieces of the data would not be copied in other places of memory during your processing of them. But most probably you don't need the data actually destroyed, you only need to mark "this place is FREE for anyone to put their data over my garbage" and that is what freeing object on Delphi actually does. If that is enough for you just don't you bother to wipe the data (which is substituting random garbage instead of sensitive garbage, but a garbage still).
Now, few words about suggestions of LU RD and whosrdaddy. Yes, Delphi provides you means to hook into the way heap is managed and to explicitly wipe the data with garbage before marking the apartment free. However this is only a partial solution for sensitive data.
99,9% of times you would be clearing data that was not worth it. Strings, dynamic arrays, TList and other containers would be slow - and your program too.
your app consists of procedures, that have local variables. Many of those variables, like Short Strings, fixed size arrays, GUIDs, are allocated on stack rather than in heap. Those suggestions would not clean them, only free.
your objects typically allocate memory in Delphi heap. But they might also allocate it otherwise. In Windows heap, in some multithreading-aware pool, or whatever. That memory would not be wiped modifying default Delphi heap manager behavior.
Overall it is the same idea. Your procedure or your object knows which data is dangerous and where it is kept - that object or procedure is responsible of cleansing. Global Delphi-scale solutions would be both ineffective and unreliable.
Is it possible to think to have in future an automatic garbage collector in Delphi? There are many applications in which a higly detailed control on when to free an object is not so important and it is just an extra thing to care about.
For such applications having a kind of garbage collector that works like java's one would be interesting.
It could be set in the project options.
Will this possible or not?
Note: I don't mean to manually create it like explained here, I really mean a Delphi feature.
Stated in another way: is it possible to set FastMM to act as Garbage collector?
There are many applications in which a higly detailed control on when to free an object is not so important and it is just an extra thing to care about.
I believe there are almost none such applications. Most of the times you think you don't require a control on when your objects are destroyed, you're potentially introducing a bug.
Now, there indeed are cases when certain objects can be safely ignored to later be dealt with by automatic collector. But keep in mind that you need to think this through for every object you're planning on not destroying manually. What if it holds some locks? What if it has some files open, maybe in share-deny mode?
There's not much of a benefit in freeing you from thinking about destroying every object, when to program safely you still need to think about destroying every object.
The purpose of garbage collectors is not to free programmers from seeing this stuff through. It's to save a bit on reference counting and try/finally calls.
Garbage collection is possible in C and C++, so I see no reason why Delphi couldn't also have such a feature. If you cross your fingers and wait long enough, Delphi might get garbage collection. I don't see it as a priority for Embarcadero, though.
You can't set FastMM to act as a garbage collector because FastMM doesn't do garbage collection, so there's nothing to set. Delphi's hypothetical future garbage-collection feature would probably have to cooperate with the memory manager, so if such a feature ever exists, and FastMM is still the memory manager at that time, then FastMM will probably gain some settings.
you have both pros and cons with garbage collection i thing delphi is good even without GC(garbage collector). even delphi apps take less memory size than managed .net apps , some times garbage collection also slow down the process because it has to find the unwanted resources , confirm whether they are needed again and delete it.if it needed again it has to load again( app becomes slow) or an error there so delphi is good without GC manually freeing is good for a professional programmer
lasted versions of delphi coming with RTTI (this is also a reason for the big size of apps)
i think rtti(Runtime Type Information) can help us in future . because it hold some informations about the process going on so i think may be in future some similar function like garbage collector is possible but not sure
but delphi for dot net 2007 and other old delphi dot net have garbage collector + vcl but now deprecated (the garbage collector also dont work 100% well)
Since http is stateless, every request to an app creates a new object. How does Rails clean up the unused objects / how frequently?
Simple answer: the Ruby runtime has a garbage collector. Depending on the runtime (JRuby/JVM generational GC, IronRuby/CLR generational GC, classic Ruby/mark-sweep GC) different algorithms are used. But the basics are pretty simple:
Upon an allocation request if there is "insufficient free memory" available - how much is insufficient is one of the ingredients of the GC algorithm - then a GC will commence
The GC starts by scanning roots, which are global variables and stack locations (parameters and local variables), to discover which objects are still alive; it marks each object it finds
Then, the GC process looks at links (references) inside these objects, and recurses into those objects that haven't already been marked
The GC can then start moving / copying all marked objects so that they are compacted in memory
The "free pointer", from whence new allocations occur, is reset to the end of this compacted chunk of memory
If there is still "insufficient free memory", then more is allocated from the operating system
All old objects that weren't marked during the scanning process are garbage and are implicitly discarded through the copying process and resetting of the free pointer.
The frequency of collections depends on the tuning of the GC, which may be affected by the operating system, the amount of physical memory, operating system memory pressure, user-controlled tweaks, underlying platform version revisions, dynamically optimized parameters, etc. Much of it comes down to deciding where the bar lies in that "insufficient free memory" test, though things get more complicated with generational collectors.
If you are interested in this you should check out the blog series about copy-on-write garbage collection by the Phusion team and their efforts to improve on the default ruby gc scheme in Ruby Enterprise Edition.
http://izumi.plan99.net/blog/index.php/2007/04/05/saving-memory-in-ruby-on-rails/
Other links in the series here:
http://www.rubyenterpriseedition.com/faq.html