3 ms·

Forgive my ignorance but what does 100% Precise GC means?

voidlogic 13y ago
http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Precise_vs._conservative_and_internal_pointers http://en.wikipedia.org/wiki/Garbage_collection_%28computer_... :)
deleted 13y ago
[deleted]
tomp 13y ago
Languages that support pointer arithmetic have to support "raw" pointers, i.e. pointers that point to any location in memory. This creates some problems for the GC, as it can't be sure what objects are live and which aren't. For example, a pointer might point to unallocated memory (in which case the GC must not even dereference it), to a `malloc`-allocated memory, to a GC-allocated memory, or even in the middle of a (GC-allocated or `malloc`-allocated) heap object! In addition, some pointers look like integers and some integers look like pointers, and the GC has no idea how to distinguish them at runtime. In order to still support some kind of GC in such languages, you can write your GC to be imprecise or conservative, which means that it treats every integer that could potentially be a pointer as a pointer and assumes it is pointing to a live object. Potentially, this means that the GC thinks objects are live which are actually not, just because the programmer is using an integer which, if interpreted as a pointer, points to said object. I'm not intimately familiar with Go implementation, but I assume that they haven't bothered implementing precise stack- and register-scanning, which means that the runtime cannot distinguish pointers from integers on the stack/in the registers. That's a really hard problem in general and solving it requires quite some compiler support and runtime overhead. It looks like that is finally planned for Go 1.3, though.
- kenshiro_o 13y ago
  I see. This indeed adds a lot more complexity to the GC as it will have to check every integer or type that "looks" like a reference. Does this also mean that GC times will likely be longer in Go 1.3? There is not much detailed info about the Go runtime (like we do have for Java for instance) so it would great for the Go maintainers to publish a more in-depth reference of the internals of the language in version 1.3 /
  - cpeterso 13y ago
    Precise (or "exactly rooted") GC should have shorter GC pause times because the runtime knows where to look for references to GC objects, rather than scanning stacks and the heap for bytes that might look like a pointer. The problem is that writing code to use precise GC is more cumbersome because you have to worry about extra bookkeeping code for every pointer reference to a GC'd object.
  - deleted 13y ago
    [deleted]
  - fulafel 13y ago
    Conservative is where you check every word that looks like a pointer. But it's simpler, it's just brute force.
- zurn 13y ago
  > Languages that support pointer arithmetic [...] To clarify, Go doesn't have pointer arithmetic. The GC has been evolving from conservative to precise, in Go 1.1 it's gotten as far as "mostly precise".
judofyr 13y ago
A conservative GC will look for memory addresses on the stack/heap and assume they're all references to objects. This means that if you have an pointer-like value (e.g. an integer in the same range as where your objects are stored), the garbage collector will (falsely) think you're referencing this object and it will be not collected. A precise GC knows exactly what data on the stack/heap are object references and only scans these.
Volundr 13y ago
It means that the GC always be able to collect all free memory. This is as opposed to a conservative GC that may fail to collect memory if there is an object that looks like it could be a pointer to it, but isn't. See: http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Precise_vs._conservative_and_internal_pointers http://en.wikipedia.org/wiki/Garbage_collection_%28computer_...
mratzloff 13y ago
Having a couple of times ran into the issue of Go not knowing to free some memory that is unused, and not being able to manually free it (or hint that it should be freed), and thus having to do some really janky hacks to make Go free it--this is really good news.

http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Precise_vs._conservative_and_internal_pointers http://en.wikipedia.org/wiki/Garbage_collection_%28computer_... :)

deleted 13y ago

[deleted]

tomp 13y ago

Languages that support pointer arithmetic have to support "raw" pointers, i.e. pointers that point to any location in memory. This creates some problems for the GC, as it can't be sure what objects are live and which aren't. For example, a pointer might point to unallocated memory (in which case the GC must not even dereference it), to a `malloc`-allocated memory, to a GC-allocated memory, or even in the middle of a (GC-allocated or `malloc`-allocated) heap object! In addition, some pointers look like integers and some integers look like pointers, and the GC has no idea how to distinguish them at runtime. In order to still support some kind of GC in such languages, you can write your GC to be imprecise or conservative, which means that it treats every integer that could potentially be a pointer as a pointer and assumes it is pointing to a live object. Potentially, this means that the GC thinks objects are live which are actually not, just because the programmer is using an integer which, if interpreted as a pointer, points to said object. I'm not intimately familiar with Go implementation, but I assume that they haven't bothered implementing precise stack- and register-scanning, which means that the runtime cannot distinguish pointers from integers on the stack/in the registers. That's a really hard problem in general and solving it requires quite some compiler support and runtime overhead. It looks like that is finally planned for Go 1.3, though.

kenshiro_o 13y ago
I see. This indeed adds a lot more complexity to the GC as it will have to check every integer or type that "looks" like a reference. Does this also mean that GC times will likely be longer in Go 1.3? There is not much detailed info about the Go runtime (like we do have for Java for instance) so it would great for the Go maintainers to publish a more in-depth reference of the internals of the language in version 1.3 /
- cpeterso 13y ago
  Precise (or "exactly rooted") GC should have shorter GC pause times because the runtime knows where to look for references to GC objects, rather than scanning stacks and the heap for bytes that might look like a pointer. The problem is that writing code to use precise GC is more cumbersome because you have to worry about extra bookkeeping code for every pointer reference to a GC'd object.
- deleted 13y ago
  [deleted]
- fulafel 13y ago
  Conservative is where you check every word that looks like a pointer. But it's simpler, it's just brute force.
zurn 13y ago
> Languages that support pointer arithmetic [...] To clarify, Go doesn't have pointer arithmetic. The GC has been evolving from conservative to precise, in Go 1.1 it's gotten as far as "mostly precise".

judofyr 13y ago

A conservative GC will look for memory addresses on the stack/heap and assume they're all references to objects. This means that if you have an pointer-like value (e.g. an integer in the same range as where your objects are stored), the garbage collector will (falsely) think you're referencing this object and it will be not collected. A precise GC knows exactly what data on the stack/heap are object references and only scans these.

Volundr 13y ago

It means that the GC always be able to collect all free memory. This is as opposed to a conservative GC that may fail to collect memory if there is an object that looks like it could be a pointer to it, but isn't. See: http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Precise_vs._conservative_and_internal_pointers http://en.wikipedia.org/wiki/Garbage_collection_%28computer_...

mratzloff 13y ago

Having a couple of times ran into the issue of Go not knowing to free some memory that is unused, and not being able to manually free it (or hint that it should be freed), and thus having to do some really janky hacks to make Go free it--this is really good news.