Denis Koroskin wrote:
On Fri, 20 Nov 2009 19:24:05 +0300, dsimcha <dsim...@yahoo.com> wrote:
== Quote from Travis Boucher (boucher.tra...@gmail.com)'s article
dsimcha wrote:
> == Quote from Denis Koroskin (2kor...@gmail.com)'s article
>> On Fri, 20 Nov 2009 17:28:07 +0300, dsimcha <dsim...@yahoo.com>
wrote:
>>> == Quote from Travis Boucher (boucher.tra...@gmail.com)'s article
>>>> dsimcha wrote:
>>>>> == Quote from Travis Boucher (boucher.tra...@gmail.com)'s article
>>>>>> Sean Kelly wrote:
>>>>>> Its harder
>>>>>> to create a memory leak in D then it is to prevent one in C.
>>>>> void doStuff() {
>>>>> uint[] foo = new uint[100_000_000];
>>>>> }
>>>>>
>>>>> void main() {
>>>>> while(true) {
>>>>> doStuff();
>>>>> }
>>>>> }
>>>>>
>>>> Hmm, that seems like that should be an implementation bug.
Shouldn't
>>>> foo be marked for GC once it scope? (I have never used new on a
>>>> primitive type, so I don't know)
>>> It's conservative GC. D's GC, along with the Hans Boehm GC and
probably
>>> most GCs
>>> for close to the metal languages, can't perfectly identify what's a
>>> pointer and
>>> what's not. Therefore, for sufficiently large allocations
there's a high
>>> probability that some bit pattern that looks like a pointer but
isn't
>>> one will
>>> keep the allocation alive long after there are no "real"
references to
>>> it left.
>> Aren't uint array allocations have hasPointers flag set off? I always
>> thought they aren't scanned for pointers (unlike, say, void[]).
>
> Right, but they can still be the target of false pointers. In this
case, false
> pointers keep each instance of foo[] alive, leading to severe
memory leaks.
But the issue is more of a GC implementation issue then a language
issue, correct?
Yes.
Or is this an issue of all lower level language garbage
collectors?
Kinda sorta. It's possible, but not easy, to implement fully precise
GC (except
for the extreme corner case of unions of reference and non-reference
types) in a
close to the metal, statically compiled language.
Unions could be deprecated in favor of tagged unions (see an example in
Cyclone http://cyclone.thelanguage.org/wiki/Tagged%20Unions). Would that
help?
Probably not since the bit pattern of int i could still match a valid
pointer.
Foo.i = cast(int)&Foo; // for bad practice ugliness
or Foo.i = (some expression that happens to equal &Foo)
Adding extra information to a union could also have the bad side effect
of killing performance as writes would include an extra write, and
additional memory would be required (which would cause another set of
issues on how to handle alignment).
