5

What's the Gambit-C's GC mechanism? I'm curious about this for making interactive app. I want to know whether it can avoid burst GC operation or not.

amalloy
  • 89,153
  • 8
  • 140
  • 205
eonil
  • 83,476
  • 81
  • 317
  • 516
  • At the end of the day it just comes down to user-experience -- as long as there is no user *noticeable* pause... –  Jun 11 '11 at 18:45
  • http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Notes_on_Memory_Management seems to indicate ref-counting is being used, but that is some notes from 2007 (which would mean immediate releasing can occur in those cases). –  Jun 11 '11 at 18:49
  • @pst Is it result with soft-realtime application? And if it uses immediate ref-counting, how can it handle circular referencing correctly? – eonil Jun 12 '11 at 03:23
  • I don't use Gambit-C, that is just all the info I could find and I'm not even sure it directly applies -- best bet would be to ask on the ML or look at the source I think :( Modern ref-counting systems (such as CPython and PHP) use an additional cycle-detection/breaking phase to handle circular references. One benefit of ref-counting is that de-allocations can be immediately performed thus amortized (even if less efficient over the long-run). For most "interactive" applications modern Mark & Sweep / Hybrid GC's have no problem (e.g. .NET/JVM) and there is even a soft real-time JVM. –  Jun 12 '11 at 05:43

2 Answers2

2

According to these threads:

Gambit has traditional stop-the-world GC at least until September 2008. People in thread recommended using pre-allocated object pooling to avoid GC operation itself. I couldn't find out about current implementation.

*It's hard to agree with the conversation. Because I can't pool object not written by myself and finally full-GC will happen at sometime by accumulated small/non-pooled temporary objects. But the method mentioned by @Gregory may help to avoid this problem. However, I wish incremental GC added to Gambit :)

eonil
  • 83,476
  • 81
  • 317
  • 516
1

According to http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Debugging#Garbage_collection_threshold gambit has some controls:

Garbage collection threshold

Pay attention to the runtime options h (maximum heapsize in kilobytes) and l (livepercent). See the reference manual for more information. Setting livepercent to five means that garbage collection will take place at the time that there are nineteen times more memory allocated for objects that should be garbage collected, than there is memory allocated for objects that should not. The reason the livepercent option is there, is to give a way to control how sparing/generous the garbage collector should be about memory consumption, vs. how heavy/light it should be in CPU load.

You can always force garbage collection by (##gc).

If you force garbage collection after some small number of operations, or schedule it near continuously, or set the livepercent to like 90 then presumably the gc will run frequently and not do very much on each run. This is likely to be more expensive overall, but avoid bursts of expense. You can then fairly easily budget for that expense to make the service fast despite.

Gregory Marton
  • 1,429
  • 10
  • 12