On 2008-12-13 04:24:54 +0100, dsimcha <dsimcha@yahoo.com> said:

> == Quote from Christopher Wright (dhasenan@gmail.com)'s article
>> It means that you can't use one block for objects of multiple types.
> 
> Sure you can, without being any worse off than under the current scheme.  Mark the
> contents of the memory as an array of void*s.  This would have the same effect as
> marking it for GC scanning under the current scheme, basically making the GC scan
> the block conservatively.  Furthermore, if you're storing value types or pointers
> to reference types that also have a pointer stored in a GC-scanned block, set the
> typeinfo to byte or something, and you have the equivalent of setting the NO_SCAN bit.

it should be an array of void (or union pointer, non pointer), they should be pinned.
Also all pointers given to C (and potentially pointers reachable from them) should be pinned.
This makes system programming difficult.
If one has a closed system with just D then it is easier.

Fawzi

dsimcha wrote:
> == Quote from Christopher Wright (dhasenan@gmail.com)'s article
>> It means that you can't use one block for objects of multiple types.
> 
> Sure you can, without being any worse off than under the current scheme.  Mark the
> contents of the memory as an array of void*s.  This would have the same effect as
> marking it for GC scanning under the current scheme, basically making the GC scan
> the block conservatively.  Furthermore, if you're storing value types or pointers
> to reference types that also have a pointer stored in a GC-scanned block, set the
> typeinfo to byte or something, and you have the equivalent of setting the NO_SCAN bit.

If you regularly do that, you won't have a moving garbage collector. If you do that only when you're low on memory, that might be acceptable.

Sean Kelly wrote:
> dsimcha wrote:
>>
>> What are the odds that some D implementation gets a moving GC in the
>> foreseeable future?
> 
> Minuscule.  The GC isn't provided nearly enough type information to safely move memory right now, and I don't see that changing any time soon.
> 
> 
> Sean

An related case that could probably be done is pure functions. Inside a pure function, all allocations could be made on a 'pure heap' instead of the normal heap. When returning from a pure function back into a non-pure function, copy the return value into the normal heap (moving it in the process). Then discard the entire pure heap.
(This is a *huge* win if the return value from the pure function is a POD, and the pure function does extensive memory allocation).

Of course, that's more like a memory pool rather a gc.

"Sean Kelly" wrote
> == Quote from Christopher Wright (dhasenan@gmail.com)'s article
>>
>> This isn't unreasonable, and it really just depends on how complete and how fast D's runtime reflection is.
>
> This would incur more memory overhead as well.  Right now, we make do with one bit per block that indicates whether the block should be scanned for pointers, while this may theoretically require a pointer to TypeInfo per block in order to perform precise scanning.

You need a bitfield indicating which ptr-sized blocks are valid pointers.

For example, a 16-byte block (on 32-bit system) only requires 4 bits.

For 16, 32, 64, 128 byte blocks, you can probably get away with just a bitfield per block.

For larger ones, you may have to have a pointer to a bitfield.  But the bitfield should also always contain a bit that says whether the block is an array.  That way, you only need one bitfield per element (i.e. the bit pattern repeats).

Perhaps, you have one bit that says whether the block is an array, one bit that says whether the 'bitfield' is really a pointer to a static bitfield (for larger elements).

These bitfields can easily be stored with the TypeInfo by the compiler.

-Steve

dsimcha wrote:
<snip>
> What are the odds that some D implementation gets a moving GC in the
> foreseeable future?

I think the underlying question is: Has anybody yet foreseen
http://d.puremagic.com/issues/show_bug.cgi?id=679
being fixed?

> Are they significant enough that I should avoid relying on the GC being non-moving, or is worrying about such things just overdoing trying to be future-proof?

Depends on whether you're writing an application or a library, I guess.

Stewart.