I'm not familiar with ocaml, but I'm pretty sure .NET garbage collector is more interesting, much more advanced and faster.
Why you find ocaml GC interesting? How does it work?
How does it solve problem of suddenly taking >16msec and missing my frame?
Why you find ocaml GC interesting? How does it work?
How does it solve problem of suddenly taking >16msec and missing my frame?
Edited by Mārtiņš Možeiko
on
Basically, it has a minor heap and major heap where objects are deallocated in blocks. Objects have a lifetime management cycle. the minor heap gets deallocated more frequently than the major heap (which contains objects that have survived from the minor heap). I believe that objects with no longer life gets deallocated when the heap is full but take it with a grain of salt.
Honestly, I don't really know if it does solve the problem that you have exposed to me. I'm a rookie it is why I'm asking to more experimented guys.
this is from the doc
--------------------
When there isn’t enough memory available to satisfy an allocation request from the pool of allocated heap blocks, the runtime system invokes the garbage collector (GC). An OCaml program can’t explicitly free a value when it is done with it. Instead, the GC regularly determines which values are live and which values are dead, i.e., no longer in use. Dead values are collected and their memory made available for reuse by the application.
The GC doesn’t keep constant track of values as they are allocated and used. Instead, it regularly scans them by starting from a set of root values that the application always has access to (such as the stack). The GC maintains a directed graph in which heap blocks are nodes, and there is an edge from heap block b1 to heap block b2 if some field of b1 is a pointer to b2.
[...]
The usual OCaml programming style involves allocating many small variables that are used for a short period of time and then never accessed again. OCaml takes advantage of this fact to improve performance by using a generational GC.
Honestly, I don't really know if it does solve the problem that you have exposed to me. I'm a rookie it is why I'm asking to more experimented guys.
this is from the doc
--------------------
When there isn’t enough memory available to satisfy an allocation request from the pool of allocated heap blocks, the runtime system invokes the garbage collector (GC). An OCaml program can’t explicitly free a value when it is done with it. Instead, the GC regularly determines which values are live and which values are dead, i.e., no longer in use. Dead values are collected and their memory made available for reuse by the application.
The GC doesn’t keep constant track of values as they are allocated and used. Instead, it regularly scans them by starting from a set of root values that the application always has access to (such as the stack). The GC maintains a directed graph in which heap blocks are nodes, and there is an edge from heap block b1 to heap block b2 if some field of b1 is a pointer to b2.
[...]
The usual OCaml programming style involves allocating many small variables that are used for a short period of time and then never accessed again. OCaml takes advantage of this fact to improve performance by using a generational GC.
sounds like a tradeoff between per-object overhead and false positives of an dead value in an live block keeping alive another dead block which in turn can keep yet other blocks alive.
Typically mark-and-sweep collectors like this does compacting after scanning of heaps. So there is not false positives of keeping live blocks with dead values around. After all live objects are copied to new place, old block of heap is released.
That's pretty much what any modern GC-collected language does. .NET does this, Java does this, etc.
.NET, for example, has 3 generations - 0, 1, 2. When small objects are allocated they go into gen0 collections only. When they survive long enough they get promoted to higher gen collection. Large objects goes into separate heap that are not compacted.
Scanning for live objects mark-and-sweep style is pretty standard method. Nothing special about ocaml. Modern .NET & Java versions have pretty advanced mark-and-sweep style compacting collector. They can use multiple threads to be faster. They can do incremental scans to not take too much time. They do not suspend all threads, but does part of collection while some threads are still running (old style mark-and-sweep collectors always suspended all managed threads when doing GC).
Here are bunch of articles on .NET GC: https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/
That's pretty much what any modern GC-collected language does. .NET does this, Java does this, etc.
.NET, for example, has 3 generations - 0, 1, 2. When small objects are allocated they go into gen0 collections only. When they survive long enough they get promoted to higher gen collection. Large objects goes into separate heap that are not compacted.
Scanning for live objects mark-and-sweep style is pretty standard method. Nothing special about ocaml. Modern .NET & Java versions have pretty advanced mark-and-sweep style compacting collector. They can use multiple threads to be faster. They can do incremental scans to not take too much time. They do not suspend all threads, but does part of collection while some threads are still running (old style mark-and-sweep collectors always suspended all managed threads when doing GC).
Here are bunch of articles on .NET GC: https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/