开发者

What's the Gambit-C's GC mechanism?

开发者 https://www.devze.com 2023-03-12 11:30 出处:网络
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.According to these threads:

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.


According to these threads:

  • https://mercure.iro.umontreal.ca/pipermail/gambit-list/2005-December/000521.html
  • https://mercure.iro.umontreal.ca/pipermail/gambit-list/2008-September/002645.html

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 :)


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号