On 1/13/2014 12:57 PM, Brad Roberts wrote:
> The key advantage that moving gives to a GC is to allow it to have a block of
> memory that it can do allocations out of by simply bumping the pointer.  When
> that region is full, a minor collection kicks in, moving anything still alive
> out to a different block of memory, then reset the region for re-use.  Pinned
> objects == region can't be emptied for reuse.  That leads to fragmentation and
> free list maintenance and you're right back with a more typical allocator.
>
> Not to say there aren't other ways of doing things, but with random objects
> becoming pinnable puts a big damper on things unless you can identify all the
> objects that might be pinned and isolate them.  But I doubt that's really
> knowable up front.

The reason pinning doesn't particularly impede this is because pinning is rare.

On 01/13/2014 10:08 PM, Dmitry Olshansky wrote:
> 13-Jan-2014 22:44, "Ola Fosheim Grøstad"
> <ola.fosheim.grostad+dlang@gmail.com>" пишет:
>> On Monday, 13 January 2014 at 17:56:12 UTC, Dmitry Olshansky wrote:
>>> Precisely. Since C space has no type information you have to
>>> conservatively assume that everything can be a pointer.
>>
>> I think we are misunderstanding each other? I don't think a Boehm style
>> GC can do compaction, since you cannot modify the "pointer", hence you
>> have to "pin down" the object it possibly points to (to prevent it from
>> moving)?
>
> So what? It can't move it and as such there is nothing special about it,
> it doesn't _cost_ anything to pin object.
>

Yes, there is a cost. The requirement to pin arbitrary objects at arbitrary times, without the possibility to move at pinning time, invalidates GC algorithms that depend on being able to move _all_ objects within some pool.

On Monday, 13 January 2014 at 21:08:50 UTC, Dmitry Olshansky wrote:
> So what? It can't move it and as such there is nothing special about it, it doesn't _cost_ anything to pin object.

Well, the advantage of compaction is that you (in theory) can relocate objects so that you:

1. get temporal and spatial coherency (sitting on the same page, to avoid paging)
2. get rid of fragmentation (less paging, requires smaller address space)
3. can have a faster and simpler allocator

If you start using the GC heap for "malloc" with pinning, you loose a lot of that? That's the cost.

Am 13.01.2014 18:45, schrieb Dmitry Olshansky:
> 13-Jan-2014 13:20, Rainer Schuetze пишет:
>>
>> Maybe I'm too pessimistic ;-) I guess moving in general could be ok, I
>> was thinking about segregating heaps by type (shared/immutable/mutable)
>> and moving data between them adds restrictions. I'd like to be proven
>> wrong.
>>
>> Some thoughts regarding a moving collector:
>>
>
>> Having to explicitely pin every pointer passed to C functions would be
>> very expensive.
>
> How would it be expensive? I don't see a need to do anything to "pin" a
> memory block, at the time of scanning there will be a potential pointer
> to it (in the stack space of C function or registers).
>

I also don't see how that would be expenive. Pinning is a common pratice in other garbage collected languages. But your argument is invalid. As the D garbage collector does not have any information about the stack frames of the C functions it simply has to ignore those (assuming its a truly percise GC).

Am 13.01.2014 21:44, schrieb Walter Bright:
>
>
> A moving GC is already supported by D's semantics.
>
> Unions are dealt with by 'pinning' those objects, i.e. simply don't move
> them. I know this can work because I implemented a mostly copying
> generational collector years ago for Java. (After I invented this,
> someone else came out with a paper about a "mostly copying" collector,
> so I didn't get any credit. Oh well! But the idea is sound and it works
> in the real world.)

I would prefer a option where the user can specifiy a function to scan classes / structs that contain unions percisely instead of pinning it.
In generall I would want a option to specify a manual scanning function for any block of GC managed memory, D is a systems programming language after all and specifing a custom scanning functionn can be a lot more effective then assuming the worst possible case for that memory block.

On 01/13/2014 10:11 PM, Walter Bright wrote:
>>
>> Not to say there aren't other ways of doing things, but with random
>> objects
>> becoming pinnable puts a big damper on things unless you can identify
>> all the
>> objects that might be pinned and isolate them.  But I doubt that's really
>> knowable up front.
>
> The reason pinning doesn't particularly impede this is because pinning
> is rare.

In Java or in D? Eg. there are no unions in Java.

Am 13.01.2014 22:31, schrieb Timon Gehr:
> On 01/13/2014 10:11 PM, Walter Bright wrote:
>>>
>>> Not to say there aren't other ways of doing things, but with random
>>> objects
>>> becoming pinnable puts a big damper on things unless you can identify
>>> all the
>>> objects that might be pinned and isolate them.  But I doubt that's
>>> really
>>> knowable up front.
>>
>> The reason pinning doesn't particularly impede this is because pinning
>> is rare.
>
> In Java or in D? Eg. there are no unions in Java.

C# has unions.

http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.structlayoutattribute%28v=vs.110%29.aspx

In theory you could use a region allocator for a pure function and copy its result out.
This wouldn't be worth it in the general case but imagine worker threads in a task pool. Pure functions executing message in/message(s) out that did not significantly contribute to the stop the world GC workload.

My D experience is only limited (mainly a C++ programmer) but something along these lines is how I have always imagined GC will sidestep the 'stop the world' problem as we move toward async/await programming models.

On 01/11/14 03:30, Rainer Schuetze wrote:
>
>
> On 10.01.2014 22:42, Andrei Alexandrescu wrote:
[snip]
>> std.emplace will continue to work as a way to build an object at a
>> specified address. I suspect that allocating and manipulating objects on
>> the GC heap in particular may have certain restrictions. One possibility
>> to avoid such restrictions is to have a function typify(T)(void* p)
>> which ascribes type T to heap location p.
>
> That sounds similar to my gc_emplace function. The problematic part is
> how to save that information in the GC.
>
[snip]
Couldn't you store a pointer to the typeinfo within the
allocated memory? IOW, the first part of the allocated memory
would be the typeinfo* followed by the actual memory used to store the
value of the allocated T object.

-regards,
Larry

On 1/13/2014 1:28 PM, Benjamin Thaut wrote:
> Am 13.01.2014 21:44, schrieb Walter Bright:
>>
>>
>> A moving GC is already supported by D's semantics.
>>
>> Unions are dealt with by 'pinning' those objects, i.e. simply don't move
>> them. I know this can work because I implemented a mostly copying
>> generational collector years ago for Java. (After I invented this,
>> someone else came out with a paper about a "mostly copying" collector,
>> so I didn't get any credit. Oh well! But the idea is sound and it works
>> in the real world.)
>
> I would prefer a option where the user can specifiy a function to scan classes /
> structs that contain unions percisely instead of pinning it.
> In generall I would want a option to specify a manual scanning function for any
> block of GC managed memory, D is a systems programming language after all and
> specifing a custom scanning functionn can be a lot more effective then assuming
> the worst possible case for that memory block.
>

I agree, but I was trying to correct the misperception that current D does not allow a moving collector.