[Issue 3112] Specification on what operations call the GC is missing

d-bugmail at puremagic.com d-bugmail at puremagic.com
Wed Dec 22 00:05:26 PST 2010


http://d.puremagic.com/issues/show_bug.cgi?id=3112


Jonathan M Davis <jmdavisProg at gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg at gmx.com


--- Comment #3 from Jonathan M Davis <jmdavisProg at gmx.com> 2010-12-22 00:03:29 PST ---
They use the GC for two reasons of which I am aware:

1. They potentially have to reallocate. That means allocating memory which
normally means using the GC. And since there's no way to tell something like ~=
to use malloc() (and potentially free()) instead of the GC, it _has_ to use the
GC.

2. As I understand it, the GC does some sort of voodoo to determine whether an
array actually has the capacity to increase its size in place. That's likely
going to have to figure out whether _other_ arrays refer to the memory
immediately after the end of the array, which would somehow involve looking at
the other arrays, which would require the GC, since one malloc-ed item knows
nothing about another malloc-ed item. The fact that you have slicing likely
complicates things a fair bit.

It would probably be possible to do array concatenation and appending without
the GC if arrays were not designed to use the GC (after all, vectors in C++ are
able to reallocate without the GC), but since they _do_ use the GC, they have
to use the GC for operations which would result in reallocating memory.

Actually, I believe that Steven pointed out on the list recently that you _can_
use appending with non-GCed dynamic arrays but that you have to maintain
references to the original before you append so that you can free that memory
if you need to. So, it _is_ possible, but it doesn't work very well.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list