Gc 是一种失败的内存管理模式


#21

Critical Path又不是critical软件。不过这不重要……

GC语言对效率的注重还是比你想象的要多的。一些商用实现中(比如lispwork里),GC并不慢。GC中断才是严重问题,而并非GC的整体效率。


#22

看你要什么。如果你要的只有计算,固然GPU可以解决问题。

如果你要的是单机尽可能多的跑Container,我不觉得现在还不可以在GPU上跑Container。


#23

既然有此致命缺陷, 那还不承认 GC 是失败的么?


#24

结合你下面的帖子,我觉得你误解我的意思。我想说的是GC和reference counting都只是在这个问题上的trade off。不是reference counting就没有它的痛处。

  • GC是为了解决内存问题。无视掉资源回收,增加了随时可能造成的pause。并且让资源回收更加隐晦
  • reference counting连内存问题都没解决。当然,牺牲的也就是个reference counting,不过是在critical path上。总体也没牺牲什么,不过不解决内存问题。只是和RAII不冲突而已。

对于那个帖子,如果你觉得我是人身攻击,那么我道歉。我的意思是,内核态,内存管理已经到了鬼斧神工的地步。而且效率敏感程度比较高(比如你在irq里多呆一会都不行),我们组已经发了一篇ASPLOS做这个事情,效率开销很难避免。从至少10%-20%到2x-6x不等。取决你做什么。而且用的方法也非常复杂。


#25

明显不是。reference counting也有致命缺陷,难道也是失败的么?

并不是很多人在乎GC pause。GC语言的用途,基本都是在开发者能够控制资源的生命周期,而不能简单思考明白内存的生命周期。而且,对于他们,bug少和高可用性可能更重要。

PS 还有个观点,没经过思考:GC能够提供代码级别的高可用性。比如热更新代码。


#26

我只是单纯的批判 GC , 没有推崇其他内存管理方式。 智能指针不是万能的, 它只是大 多数情况下工作的相当好 , 使得程序员可以安心的处理业务逻辑。

没有一种内存管理方式是万能的, GC 如此, 智能指针也是如此。 正是这样, C++ 承认内存管理的复杂性, 并尽量提供工具去帮助程序员 , 而不是强迫大家使用一种类型的内存管理模式。


#27

就是因为你对reference counting推崇的实在是让我看不下去了,我才过来回帖的。这种文章对初学者的误导十分严重——有个初学者告诉我内存管理就shared_ptr就解决所有问题了,C++那群那么聪明的人30年磨一剑啊——我才过来回帖的。

如果正如你所说,这不是你的本意,那么希望把“推崇其他内存管理”方式的话语去掉。

C++那群人不至于傻到弄个reference counting弄了30年。shared_ptr很早就在标准的draft里了,而且更早,基本是随着模板完善可用之后,boost就跟进了。发明这个东西并不需要那么长时间。之所以这么长时间,完全是模板的复杂性和新标准的跳票,而模板,很显然不是为了内存管理才发明的…………


#28

只所以说要了 30 年, 我认为直到标准确立, C++才算承认这种内存管理方式的正统性。标准化之前, 都是 experimental 的。处于试验状态。

为啥要误导初学者? NO, 没有误导。 GC 确实失败了, 这点上毋庸质疑。

shared_ptr 的方法还需要另外撰文慢慢交待。

另外, 你说我误导了你才回帖的咯? 看来你原本的打算就是 看贴不回 , 对得起辛苦码字的楼主么?!


#29

我把误导人的话这里引用一下,如果你不是推崇reference counting,就修改这些。

以上两个,其实只是利用RAII而已。shared_ptr在编译器看来,没什么特殊的。编译器不是shared_ptr aware的。


#30

正因为你不懂 C++ 所以你才会觉得这不是编译器做的事情。


#31

要等到一个解决方案正统是对的,但不意味着正统之前他就不存在。

如果你这么说,那我也可以说reference counting在一开始也没打算成功。程序员还是需要自行判断什么时候是weakref

只是我朋友看到了而已。你误导了他。如果你没误导他,我也不会回帖。


#32

看来我辛苦的救赎计划被你破坏了。

你知道破坏一个人要比拯救一个人容易多了。

refcouting 并不是万能的, 但是我们无需利用 refcounting 的错误来证明 GC 是不失败的。


#33

正因为你没有好好看RAII部分的标准,不去看clang的代码,不去看gcc的代码才觉得是编译器的事情。这就是个简单的RAII。

你说是编译器的事情,你去cite编译器代码啊?gcc哪行对shared_ptr特殊处理了?

顺便,说别人不懂C++之前,看看别人的背景和经验。


#34

reference counting不work,GC也不work。大家都不work,你拿来除了误导别人,让别人写出bug更多的代码以外,还能做点正常事情么?

有空和别人学学,多为C++ runtime写点patch,多看看clang的代码,写点tool。不比这个好? 或者,哪怕写点正常的文章。


#35

不不不, 你错了, 如果没有 RAII 没有模板就无法实现 shared_ptr .

shared_ptr 是 C++11 标准, 是 STL 的组成部分, STL 是随 编译器发行的。

你因为轻视 shared_ptr , 推崇 GC , 所以你必须 从技术角度诋毁 shared_ptr 否认 shared_ptr 的技术成就, 把他说成是 “不过如此” 的技术。 这是一种恶毒的伎俩, 可惜你面对的人错了


#36

没有什么技术水平, 只靠装逼忽悠的人, 最后的救命稻草就是 “有空多XXXXXX” 去, 这个 XXX 可以是任何事情。


#37

内核态来帮忙上层的应用程序解决memleak,至少在Linux的世界里,Linus是不太会同意的,memleak与内核一点关系没有,自然内核也不需要为解决应用层的memleak买单,内核应当保持简单。 C/C++中的内存管理也不是什么洪水猛兽,取决于人,以及使用方法,类似于nginx,Linux Kernel之类典型C/C++应用都没什么内存泄漏(我没有听说过,也没有听人提及过) 在应用层而非内核层就可以解决内存总是,Valigind/CLang提供了大量工具来辅助定位内存问题。 换句话说,C/C++的内存管理是完全可控且可解决的,但是GC是什么,基本上你无法精确控制它,于是你需要使用各种tricks来进行GC调优,类似于JVM调优。 GC带来的运行停顿,GC不及时引起的内存峰值…都是一个个定时炸弹,这是GC最大的问题


#38

STL是runtime。你clang可以选择用gcc的runtime也可以选择用libc++的runtime。早年还可以用STLPort。这是你所谓的编译器一部分?(而且clang也不随STL发行……给它gnu的STL它就能用……)

我没推崇GC。shared_ptr就是如此。有了RAII我就能写,有了模板,我能写的和boost:shared_ptr一模一样的。这个你有问题?

复杂的部分是模板和RAII。而这两个都只是C++的特性,而非内存管理方案。所以我说,shared_ptr这种东西,我可以用”标准C++“很轻松的写一个……


#39

开kmemleak,boot你的电脑。看dmesg。你就注意别被刷屏就好。


#40

看来你非要用人身攻击来证明你比C++ Runtime hacker懂C++了。