On 01/14/2014 07:29 PM, Benjamin Thaut wrote:
>
> Yes, but pinning will still be necessary for passing data to C/C++
> functions.

(I agree, it is the spec that does not.)

14-Jan-2014 21:56, Benjamin Thaut пишет:
> Am 14.01.2014 14:42, schrieb Timon Gehr:
>> On 01/14/2014 10:20 AM, Benjamin Thaut wrote:
>>> 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.
>>
>> Once it becomes known that an object should be pinned, it is too late
>> for moving. (There will then exist a potential pointer to the object.)
>
> Well no, usually you have to pin objects _before_ passing them to
> C-land. Pinning is not a automatic process its done manually (or by the
> compiler).

If one accepts that any heap can have object that is pinned I don't see why you need explicit pinning. It just becomes (a complication to) a part of normal marking stage, the discovery of which objects are pinned.
In semi-precise setting it IMHO makes perfect sense.

-- 
Dmitry Olshansky

Why are unions with pointers even allowed in the first place? It seems like a really really really bad thing to do. Am I missing some really important use case?

Am 14.01.2014 20:08, schrieb Tofu Ninja:
> Why are unions with pointers even allowed in the first place? It seems
> like a really really really bad thing to do. Am I missing some really
> important use case?

Yes, low level programming. D is supposed to be a systems programmin glanguage after all. Tagged unions are a often used concept, and pointers within these tagged unions are very common. Also its needed for compatibility with C.

Am 14.01.2014 18:53, schrieb woh:
>   If Java with all it that time and money can not create a performant
> GC, what hope has D?
>
>   Full program tracing GC is a dead horse, it does not scale, all of the
> better Java GC's require 2x or memory of the working set to actually get
> any speed
>
>
>   isolated task or allocator based memory that can use GC as a last
> resort is what you need, but D lacks in this regard

Are you aware of Azul's GC or some real time VMs like Aonix PERC?

On 1/14/2014 3:02 AM, Benjamin Thaut wrote:
> Am 14.01.2014 11:05, schrieb Walter Bright:
>> This is not true, I've implemented one for Java.
>
> So how do you implement a semi-space GC with pinned objects?

Be more flexible in what the semi-spaces are.

On Tuesday, 14 January 2014 at 19:09:00 UTC, Tofu Ninja wrote:
> Why are unions with pointers even allowed in the first place? It seems like a really really really bad thing to do. Am I missing some really important use case?

Tagged unions are very useful. For instance, to take a
simplified, but real life example, I have a function to resolve
identifier in a compiler. It can resolve as a type, as an
expression, as a template, as a package or module, or whatnot.
This is a case where you need to return an union of types (or
rely on complete type erasure).

Am 14.01.2014 21:28, schrieb Walter Bright:
> On 1/14/2014 3:02 AM, Benjamin Thaut wrote:
>> Am 14.01.2014 11:05, schrieb Walter Bright:
>>> This is not true, I've implemented one for Java.
>>
>> So how do you implement a semi-space GC with pinned objects?
>
> Be more flexible in what the semi-spaces are.

So you just don't. Effectivley you work around the problem. I would still prefer that specifing a scanning function for unions becomes mandatory.

On Tuesday, 14 January 2014 at 17:38:56 UTC, Dmitry Olshansky wrote:
> Bleh. If anything you may as well lose it - manual memory management is the only option to guarantee you something to the extent of having related object together in the same page. That is if you can make it so by hand.

Under what assumption? There is not optimal garbage collector, you have to select or adapt one that fits the application.

You can tag objects by a group id or type id and use that during compaction.

> write do *cost* something. This cost is then regained (with interest) by applying simpler and efficient algorithms such as semi-space compaction.

I wouldn't call semi-space compaction efficient, it can lead to heavy paging.

On 1/14/2014 1:10 PM, Benjamin Thaut wrote:
> Am 14.01.2014 21:28, schrieb Walter Bright:
>> On 1/14/2014 3:02 AM, Benjamin Thaut wrote:
>>> Am 14.01.2014 11:05, schrieb Walter Bright:
>>>> This is not true, I've implemented one for Java.
>>>
>>> So how do you implement a semi-space GC with pinned objects?
>>
>> Be more flexible in what the semi-spaces are.
>
> So you just don't. Effectivley you work around the problem.

My experience with book algorithms is they usually require some adjustments when working with real problems in the real world. I was well aware of how moving GCs worked when I set the semantics of D objects, since I'd implemented one, and was careful to make them possible with D.


> I would still prefer that specifing a scanning function for unions becomes mandatory.

I already agreed that there are better ways.