RSS구독하기:SUBSCRIBE TO RSS FEED
즐겨찾기추가:ADD FAVORITE
글쓰기:POST
관리자:ADMINISTRATOR
'GC'에 해당되는 글 2

In computer science, the Boehm–Demers–Weiser garbage collector, often simply known as Boehm GC, is a conservative garbage collector for C and C++.[1]

Boehm GC is free software distributed under a permissive free software licence similar to the X11 license.


The developer describes the operation of the collector as follows:

The collector uses a mark-sweep algorithm. It provides incremental and generational collection under operating systems which provide the right kind of virtual memory support. (Currently this includes SunOS[45], IRIX, OSF/1, Linux, and Windows, with varying restrictions.) It allows finalization code to be invoked when an object is collected. It can take advantage of type information to locate pointers if such information is provided, but it is usually used without such information.

http://www.hboehm.info/gc/#details

Boehm GC can also run in leak detection mode[2] in which memory management is still done manually, but the Boehm GC can check if it is done properly. In this way a programmer can find memory leaks and double deallocations.

Boehm GC is also distributed with a C string handling library called cords. This is similar to ropes in C++ (strings are trees of small arrays, and they never change), but instead of using reference counting for proper deallocation, it relies on garbage collection to free objects. Cords are good at handling very large texts, modifications to them in the middle, slicing, concatenating, and keeping history of changes (undo/redo functionality).

https://en.wikipedia.org/wiki/Boehm_garbage_collector
2017/05/18 04:59 2017/05/18 04:59
이 글에는 트랙백을 보낼 수 없습니다
[로그인][오픈아이디란?]
오픈아이디로만 댓글을 남길 수 있습니다

Conclusion

The key takeaway from this investigation is that GCs are either optimized for lower latency or higher throughput. They might also perform better or worse at these depending on the heap usage of your program. (Are there a lot of objects? Do they have long or short lifetimes?)

It is important to understand the underlying GC algorithm in order to decide whether it is appropriate for your use-case. It’s also important to test the GC implementation in practice. Your benchmark should exhibit the same heap usage as the program you intend to implement. This will check the effectiveness of the GC implementation in practice. As we saw, the Go implementation is not without faults, but in our case the issues were acceptable. I would love to see the same benchmark in more languages if you would like to contribute :)

Despite some issues, Go’s GC performs well compared to other GCed languages. The Go team have been improving the latency, and continue to do so. We’re happy with Go’s GC, in theory and practice.

Source : https://making.pusher.com/golangs-real-time-gc-in-theory-and-practice/
2017/04/13 14:25 2017/04/13 14:25
이 글에는 트랙백을 보낼 수 없습니다
[로그인][오픈아이디란?]
오픈아이디로만 댓글을 남길 수 있습니다
Dot:Where is ......
byDot
Where is ......
전체 (177)
주절거림 (60)
윈도우벽지 (2)
Shoveling.. (9)
주워들은것들.. (48)
요집이 괜찮더라!! (0)
찍사놀이 (7)
관심꺼리~ (4)
«   2024/03   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
  1. 내 맘대로 보는 세상  2009
    맘에 안드는 Internet Explorer 업데이트 방침!
  2. 시리니  2008
    브라우저 업데이트, 작지만 큰 실천입니다.
  3. Dinosur와 KM의 Blog  2007
    저도 보통 사람
  1. 2019/02 (1)
  2. 2018/07 (1)
  3. 2018/01 (11)
  4. 2017/12 (10)
  5. 2017/10 (1)