Benjamin Thaut:

> 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.

Time ago I suggested an optional standard method for unions of structs named as "onGC", that if present is used by the GC at run-time to know what to do with the contents of the unions.

Bye,
bearophile

On 01/13/2014 11:05 PM, Paulo Pinto wrote:
> 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
>

"The common language runtime controls the physical layout of the data fields of a class or structure in managed memory. However, ..."

On 2014-01-13 22:23, Timon Gehr wrote:

> 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.

Can't these object be pinned somewhere else?

-- 
/Jacob Carlborg

On Monday, 13 January 2014 at 23:42:50 UTC, Timon Gehr wrote:
> On 01/13/2014 11:05 PM, Paulo Pinto wrote:
>> 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
>>
>
> "The common language runtime controls the physical layout of the data fields of a class or structure in managed memory. However, ..."


Did you also read the remaining part of the page, or just looked for something to paste?

You can control the layout, that is what matters. Not at what level you are expressing it.

Ignoring what such runtimes offer, only puts D at disadvantage when comparing feature lists, which many in the industry do.

--
Paulo

Am 13.01.2014 23:55, schrieb Walter Bright:
>
> I agree, but I was trying to correct the misperception that current D
> does not allow a moving collector.

Current D does not allow a moving collector because of the lack of compiler support. It is still not possible to identify all pointers percicesly, especially those on the stack. Also when you want to implement a semi-space GC everything _must_ be moveable. Pinning is not an option for a semi-space GC. There for current D does not allow the implementation of semi-space GC without some changes to the spec. (E.g. structs / classes containing unions _must_ provide a custom scanning function).

Am 14.01.2014 09:15, schrieb Jacob Carlborg:
> On 2014-01-13 22:23, Timon Gehr wrote:
>
>> 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.
>
> Can't these object be pinned somewhere else?
>

Yes, thats the usual approach. But that means that you have to copy them to a other space before pinning, or allocate them in a space that allows pinning in the first place.

On 2014-01-14 10:20, Benjamin Thaut wrote:

> Yes, thats the usual approach. But that means that you have to copy them
> to a other space before pinning, or allocate them in a space that allows
> pinning in the first place.

Is there a problem to allocate them in the correct space from the beginning?

-- 
/Jacob Carlborg

Am 14.01.2014 10:52, schrieb Jacob Carlborg:
> On 2014-01-14 10:20, Benjamin Thaut wrote:
>
>> Yes, thats the usual approach. But that means that you have to copy them
>> to a other space before pinning, or allocate them in a space that allows
>> pinning in the first place.
>
> Is there a problem to allocate them in the correct space from the
> beginning?
>

Well you have to know it at allocation time. If you have a function that takes a blob of data as argument and passes it to C, the caller does not know of the requirement and you (maybe) have to copy inside the callee.

Kind Regards
Benjamin Thaut

On 1/14/2014 1:18 AM, Benjamin Thaut wrote:
> Current D does not allow a moving collector because of the lack of compiler
> support. It is still not possible to identify all pointers percicesly,
> especially those on the stack. Also when you want to implement a semi-space GC
> everything _must_ be moveable. Pinning is not an option for a semi-space GC.
> There for current D does not allow the implementation of semi-space GC without
> some changes to the spec. (E.g. structs / classes containing unions _must_
> provide a custom scanning function).


This is not true, I've implemented one for Java.

Am 14.01.2014 11:05, schrieb Walter Bright:
> On 1/14/2014 1:18 AM, Benjamin Thaut wrote:
>> Current D does not allow a moving collector because of the lack of
>> compiler
>> support. It is still not possible to identify all pointers percicesly,
>> especially those on the stack. Also when you want to implement a
>> semi-space GC
>> everything _must_ be moveable. Pinning is not an option for a
>> semi-space GC.
>> There for current D does not allow the implementation of semi-space GC
>> without
>> some changes to the spec. (E.g. structs / classes containing unions
>> _must_
>> provide a custom scanning function).
>
>
> This is not true, I've implemented one for Java.

So how do you implement a semi-space GC with pinned objects?