>[оверквотинг удален]
>
>>Угу. Продолжайте читать новости про утечки памяти в DBUS, хотя GC уже давно в любой кофеварке имеются.
>
>эта та хрень, которая сама знает что и когда выкинуть из памяти?
>
>панацея для не аккуратных программистов?
>не из-за него ли java считается тормозной и прожерливой?
>
>возможно таким программистам, которые выпускают релиз с утечкой памяти и поможет garbage
>collector, но мне кажется, что все-таки что-то другое GC хорош для программ, которые периодически выключаются. Иначе текут сильно. Не видел и не слышал ещё ни об одной реализации GC, которая бы не подтекала (не на бумаге, а по факту). На сайте того же D, например, освещаются и другие проблемы:
"When the garbage collector does a collection pass, it must pause all running threads in order to scan their stacks and register contents for references to GC allocated objects. If an ISR (Interrupt Service Routine) thread is paused, this can break the program.
Therefore, the ISR thread should not be paused. Threads created with the std.thread functions will be paused. But threads created with C's _beginthread() or equivalent won't be, the GC won't know they exist.
For this to work successfully:
* The ISR thread cannot allocate any memory using the GC. This means that the global new cannot be used. Nor can dynamic arrays be resized, nor can any elements be added to associative arrays. Any use of the D runtime library should be examined for any possibility of allocating GC memory - or better yet, the ISR should not call any D runtime library functions at all.
* The ISR cannot hold the sole reference to any GC allocated memory, otherwise the GC
may free the memory while the ISR is still using it. The solution is to have one of the paused threads hold a reference to it too, or store a reference to it in global data."
Так что GC уместен в многих отраслях прикладном ПО (более того, я всеми лапами за, ибо реально экономит нервы и программиста, и зазказчика), но не там, где нужно чётко отслеживать все операции с памятью.
