Mirror of forum.nim-lang.org

62 :: granularity of the GC

• adrianv (orginal) [2012-07-29T13:11:48+02:00] view original

  Hi,

  what is the granularity of the GC actually?

  I had some structures and was thinking, if it makes any sense at all to reduce the size of these structures if the granularity of GC is higher.

  Another thing I was thinking about if it is possible, that the GC takes only the significant bits of a ref into account. Then it would be possible to use the other bits to encode some information. I know this is hacky, but currently I have the problem with the implementation of the neko VM that the original code exactly does this (it uses bit 0 to indicate an integer value and can store up to 31 bit/ 63bit without the need of extra memory allocation). I tried a myriad of alternative solutions and the best I have come up until now is to use a different stack for each value type and a different accumulator for each type too, but this gets quite complex...

---

• Araq (orginal) [2012-07-29T13:34:03+02:00] view original

  You have quite some control over the ganularity if you enable the realtime GC: gc.txt

  I am aware of this common hack for VMs. I'm not against it, but I won't implement it. It requires quite some changes to the GC and may also slow it down; however I accept pull requests for this feature if it can be en-/disabled with for instance -d:useForgivingGC . Join the IRC channel, I'll gladly assist you to get all the invariants right. ;-)

---

• adrianv (orginal) [2012-07-29T13:59:21+02:00] view original

  to 1.) I meant memory granularity not time granularity

  to 2.) I must out myself as being ignorant to certain things - I never used IRC or something like that, so I have to first ask my kids howto (oh no - this will be a total loss of my face). But thanks yes - I will try to make the GC forgiving

---

• Araq (orginal) [2012-07-29T14:27:29+02:00] view original

  I have no idea what you mean by memory granularity: If it means "triggered after X KB" then that question cannot be answered as it depends on the code and the compiler's ability to optimize it. The underlying memory allocator allocates blocks of 1 MB iirc. Unused blocks are returned back to the OS.

---

• adrianv (orginal) [2012-07-29T15:01:15+02:00] view original

  I see, the GC uses the underlying memory manger. I meant if I have a structure which is 18 bytes and I can reduce its size to 16 bytes, it would make no sense if the memory manger allocates no smaller blocks than 32bytes, but if it allocates blocks with 16 bytes it would make sense.

---

• Araq (orginal) [2012-07-29T15:25:10+02:00] view original

  Oh that's what you mean... Granularity is 8 bytes then.

---

• Araq (orginal) [2012-07-30T00:23:36+02:00] view original

  Another thing I was thinking about if it is possible, that the GC takes only the significant bits of a ref into account. Then it would be possible to use the other bits to encode some information.

  BTW the new thing is using float64 as the underlying object representation and encoding pointers and integers as special NaN values as current CPUs only produce a single NaN bit pattern; all the other bit patterns representing NaN are free to abuse. Luajit does this for instance. Of course this is even more work to implement and to make it play nice with Nimrod's GC.

---