重新宣布GC的缺陷 [英] A re-announce on GC's defects

问题描述

GC真的是垃圾本身


原因1：


想要的破坏与实际破坏之间存在延迟。


破坏延迟造成的负面影响：


1）效率问题


这对于CPU /资源密集但内存便宜的对象。


CPU密集型对象引用拥有内部线程的对象。


资源密集型对象引用对象谁拥有非托管资源，如

文件句柄，网络连接等。


别告诉我这些对象很少见。一切都有可能发生，并且

通用语言不应该找不到适用于某些

情况的借口。


2）逻辑问题


弱引用的需要使得破坏延迟在逻辑上不正确。


弱引用（或者你可以称它们为句柄）参考谁做的参考

不要求参考目标保持活力，而强引用

。


当所有强者对目标的引用超出了他们的生命，目标

也会在其生命周期结束时出现。在这一点上，对这个目标的弱引用

变得无效。但是，由

GC引起的破坏延迟违反了这一逻辑。在GC真正收集目标对象之前，弱引用将继续认为目标是活生生的。


不要告诉我IDispose模式是为了那个。可能有多个

强引用，你不知道何时何地拨打Dispose。


别告诉我WeakReference（ C＃）就是为了这个。如果你没有正确调用Dispose

，WeakReference仍然会给出错误的逻辑。


不要告诉我这可以通过添加来解决像IsDestroyed这样的方法到

目标。它对太阳持有蜡烛，它只会增加

逻辑的复杂性。


例如：


假设我们正在做3D游戏。雷达正在监视目标。显然，雷达应该对目标保持弱参考。当目标被杀死时，逻辑混乱立即被带到雷达观察者（

游戏玩家）。目标是否被摧毁？你不能告诉他，嘿，它已经被杀死但仍然显示在雷达上，因为你必须等待GC来赚取它。


原因2：


可扩展性差


这是一个理论问题。


GC是全局的，这意味着它可以根据应用程序的内存使用规模进行扩展。

从理论上讲，这表明可扩展性不佳。

不要告诉我应用程序不应该使用太多的并发对象。

再一次，一切皆有可能。限制只能证明

语言的缺陷。


相对而言，GC本身并不是垃圾。但是，当java和C＃

集成它并阻止用户手动管理内存时，它变成了b $ b $垃圾。注意java和C＃中的GC并不是真的让人上瘾，因为有人会因为没有办法像在b
C ++中删除obj那样进行真正的内存管理。


更好的内存管理在我的脑海里是引用计数+智能指针，

使事情自动和正确。你有确定性的

destructions而不需要手动调用Dispose。你不需要手动更改引用计数，因为智能指针可以帮助你实现它。

这种方法的唯一问题是循环引用。然而，即使理论上没有证明

，通常可以通过用弱引用代替

一些强引用来解决问题。


我认为GC的限制是导致某些领域的主要原因之一

（例如游戏行业），java或C＃很少用于严重的

面临真正计算挑战的产品。


解决方案


1）理想的解决方案是说服语言提供商给我们回馈
我们自己管理内存的能力。 GC仍然存在，并且在这种情况下它会变成真正让人上瘾的。


2）将负担转移给用户。我们可以要求用户始终采取

特别注意事项（例如，始终在C＃中使用使用以使Dispose

正确调用甚至发生异常）。如果用户

做得对，那么事情就可以解决。然而，这本身就存在风险，而不是一个强大的解决方案。

GC is really garbage itself

Reason 1:

There is delay between the wanted destruction and the actual destruction.

Negative effects by the destruction delay:

1) Efficiency issue

It''s bad for CPU/Resource intensive but memory cheap objects.

CPU intensive objects refer to objects who own internal threads.

Resource intensive objects refer to objects who own unmanaged resources like
file handle, network connections, etc.

Don''t tell me these objects are rare. Everything is possible to happen and a
general purpose language should not find any excuse not to apply to some
situations.

2) Logic issue

The need for weak reference makes the destruction delay logically incorrect.

Weak references (or you can call them handles) refer to references who do
not require the referenced targets to keep alive, while strong references
do.

When all strong references to a target go out of their lifetime, the target
also comes to the end of its lifetime. Right at this point, weak references
to this target become invalid. However, the destruction delay caused by the
GC violates this logic. Weak references will continue to think the target
alive until the GC really collects the target object.

Don''t tell me the IDispose pattern is for that. There may be more than one
strong references and you don''t know when and where to call Dispose.

Don''t tell me WeakReference (C#) is for that. If you don''t have Dispose
called properly, WeakReference still gives a wrong logic.

Don''t tell me this can be solved by adding method like IsDestroyed to the
target. It holds a candle to the sun and it only adds to the complexity of
logics.

An example:

Suppose we''re doing a 3D game. A radar is monitoring a target. Obviously,
the radar should hold a weak reference to the target. When the target is
killed, logical confusion is immediately brought to the radar watcher (the
gamer). Is the target destroyed or not? You can not tell him, hey, it''s
killed but still shown on the radar because you''ve got to wait for the GC to
make it.

Reason 2:

Poor scalability

This is a Theory issue.

GC is global, which means it scales as the application''s memory use scales.
Theoretically, this indicates a bad scalability.

Don''t tell me an application should not use too many concurrent objects.
Again, everything is possible. Restrictions only prove the defects of the
language.

Fairly speaking, GC itself is not garbage. However, when java and C#
integrate it and prevent the user from manually managing memory, it becomes
garbage. Note GC in java and C# is not really an addictive as someone would
argue since there is no way to do real memory management like delete obj in
C++.

Better memory management in my mind is reference counting + smart pointer,
which makes things automatic and correct. You have deterministic
destructions while no need to manually call Dispose. You need not to
manually change the reference count as smart pointers help you achieve it.
The only problem with this approach is cyclic reference. However, even if
not theoretically proven, the problem generally can be solved by replacing
some strong references with weak references.

I believe the restriction by GC is one of the main reasons why in some field
(the gaming industry, for example), java or C# is rarely used in serious
products who face real computing challenges.

Solution

1) The ideal solution is to convince the language providers to give us back
the ability of managing memory by our own. GC can still be there, and it
becomes a real addictive in that situation.

2) Transfer the burden to the user. We can ask the user to always take
special cautions (for example, always use "using" in C# to have Dispose
correctly called even exception occurs). Things can work around if the user
do them right. However, that''s at risk in nature and not a robust solution.

推荐答案

Born写道：

Born wrote:

GC实际上是垃圾本身

GC is really garbage itself

[snip]

[snip]

更好的内存管理我的想法是引用计数+智能指针，

Better memory management in my mind is reference counting + smart pointer,

所以坚持使用C ++ ......

So stick with C++ ...

事情是自动和正确的。

which makes things automatic and correct.

....因为毕竟，C ++因其程序永远不会有任何与内存分配相关的错误而闻名。


哦等等。

.... because after all, C++ is famous for its programs never having any
kind of memory-allocation-related bugs.

Oh wait.

我相信GC的限制是某些领域的主要原因之一

（例如游戏行业），java或C＃很少用于面临真正计算挑战的严重产品。

I believe the restriction by GC is one of the main reasons why in some field
(the gaming industry, for example), java or C# is rarely used in serious
products who face real computing challenges.

对你有多好。有这种信念的证据，还是盲目信仰？

-

拉里拉德
la ******* @ googlemail.com

地址是真实的，但未读 - 请回复群组

对于VB和C＃问题 - 告诉我们哪个版本

How nice for you. Any evidence for this belief, or is it blind faith?
--
Larry Lard
la*******@googlemail.com
The address is real, but unread - please reply to the group
For VB and C# questions - tell us which version

我认为你实际上错过了很多非常重要的原因，因为GC

是坏的。我一直讨厌它。但我们的选择很少。它是

我们使用.Net并且有一个GC或我们使用Win 32编译的应用程序

用C ++或Delphi编写。没有什么要求我们使用.Net。


-

Michael

----
http://michael.moreno.free.fr/
http://port.cogolin.free.fr/

I think you have actually missed many very important reasons why the GC
is bad. I hate it all the way. But we have very little choice. It is
either we use .Net and there is a GC or we use Win 32 compiled app
written in C++ or Delphi. Nothing obliges us to use .Net.

--
Michael
----
http://michael.moreno.free.fr/
http://port.cogolin.free.fr/

你好生，


BGC真的是垃圾本身

B>

BReason 1：

B>

BThere是想要破坏和实际

Bdestruction之间的延迟。

B>

B破坏延迟造成的负面影响：

B>

B1）效率问题


这真的很糟糕吗？ :)它只取决于你的应用程序上下文。如果它没有

符合您的要求欢迎回到非管理世界，手动记忆

管理


B2）逻辑问题
B>

B弱参考需要逻辑上的破坏延迟

Bincorrect。


缓存是在逻辑上也是不正确的？


B这种方法的唯一问题是循环

干扰。然而，即使理论上没有证明，问题也可以通过用弱的替换一些强大的参考来解决这个问题。


但它在逻辑上是错误的，正如之前提到的那样:)


BI认为GC的限制是导致

Bsome字段的主要原因之一（例如游戏行业），java或C＃很少用于b $ b b在面临真正计算挑战的严肃产品中使用。


lol

严重产品是什么？和真实计算挑战对你来说意味着什么？


FPS？ :)


BTW，最后的DX样本都在C＃中。 C＃和游戏行业的真正挑战

是性能。

在2 - 3年内它将被解决

BSolution

B>

B1）理想的解决方案是说服语言提供商给予

巴士返回我们自己管理内存的能力。 GC仍然可以在这种情况下成为一个真正令人上瘾的东西。


没有人禁止你使用C ++

---

WBR，

Michael Nemtsev [C＃MVP] ::博客： http://spaces.live.com/laflour


对我们大多数人来说最大的危险不是我们的目标太高了，我们想念它，但它太低了，我们就达不到它了。 （c）米开朗基罗

Hello Born,

BGC is really garbage itself
B>
BReason 1:
B>
BThere is delay between the wanted destruction and the actual
Bdestruction.
B>
BNegative effects by the destruction delay:
B>
B1) Efficiency issue

Does it really bad? :) It only depends on your app context. If it doesnt
meets your requirement welcome back to unmanaged world with manually memmory
management

B2) Logic issue
B>
BThe need for weak reference makes the destruction delay logically
Bincorrect.

Caching is the logically incorrect too?

BThe only problem with this approach is cyclic
Breference. However, even if not theoretically proven, the problem
Bgenerally can be solved by replacing some strong references with weak
Breferences.

But it''s logically incorrect, as mentioned before :)

BI believe the restriction by GC is one of the main reasons why in
Bsome field (the gaming industry, for example), java or C# is rarely
Bused in serious products who face real computing challenges.

lol
What does the "serious product" and "real computing challenge" mean for your?

The FPS? :)

BTW, last DX samples are in C#. The real challenge of C# and game industry
is performance.
In 2 - 3 years it will be solved
BSolution
B>
B1) The ideal solution is to convince the language providers to give
Bus back the ability of managing memory by our own. GC can still be
Bthere, and it becomes a real addictive in that situation.

Nobody prohibits u to use C++
---
WBR,
Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

这篇关于重新宣布GC的缺陷的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！