On 5/11/2014 1:45 PM, Rainer Schuetze wrote:
>
>
> On 11.05.2014 22:33, Walter Bright wrote:
>>
>>>> The Boehm collector cannot move objects around, the D one can.
>>> Oh it can? Really?
>>
>> Yes. D, for example, requires that objects not be self-referential for
>> this reason.
>
> I don't think the GC would have problems with fixing up internal pointers to the
> object itself. self-referential is prohibited to allow moving structures by
> memcpy, e.g. as return value.

The earlier D design did not have postblit, and so there was no fixing up of internal pointers.

On 5/11/2014 1:43 PM, Michel Fortin wrote:
> It is a variation on that scheme, but with one significant difference: those two
> pointer types can mix and there's no restriction on assignments from one type to
> the other. There's therefore no transitive effect and no complicated ownership
> rule to understand.
>
> This obviously does not address all your concerns with ARC (which I'll admit
> most are valid), but this "ARC isn't memory-safe" argument has to stop. It does
> not make sense. One doesn't need to sacrifice memory safety to use ARC, neither
> is that sacrifice necessary for having islands of non-ARC code. That's what I
> was trying to point out in my previous post.

As long as C++/CX and O-C are brought out here as proven, successful examples for D to emulate here, and there is no acknowledgement that they are not remotely memory safe, I need to continue to point this out.

Rust is memory safe, but is an unproven design.

Your proposal still relies on a GC to provide the memory safety, and has no inherent protection against GC pauses. Your idea has a lot of merit, but it is a hybrid ARC/GC system.

On Sunday, 11 May 2014 at 11:42:37 UTC, ponce wrote:
> On Sunday, 11 May 2014 at 08:59:42 UTC, Walter Bright wrote:
>>
>> D also cannot be performance competitive with C++ if pervasive ARC is used and memory safety is retained. Rust is attempting to solve this problem by using 'borrowed' pointers, but this is unproven technology, see my reply to Manu about it.
>
> I work in a C++ shop and as I see it, resource management is becoming a solved problem:
>
> - resource owners holds a std::unique_ptr<T> on them. Resource release is taken care by C++ destructors normally. That means to be exception-safe, each resource type must better have its class.
> - resource users eventually "borrow" the resource by taking a raw pointer out of the unique pointer. What Rust would do with lifetimes here is ensure that the resource is still there since move semantics seems pervasive in this language. In C++ we ensure the resource holder outlive the users.
> - std::shared_ptr is not needed with such constraints. This means no cycles in the object graph. TBH I have yet to find a dependency scheme that can't be done that way.
>
> When I use D I can't help but think that releasing resources feels more manual and error-prone ("oops that resource should have been a struct not a class" and such traps).
>
> I do not have huge concerns about D GC, but I would be glad to have more support for owned pointers (ie. Unique!T in Phobos or better). I have no idea how to make it safe ie. ensure the resource outlive its users.

I like this owner/unique, borrow thing.

@ is managed (currently reference counted)
~ is owner
     & is borrow

fn example3() -> int {
    let mut x = ~X {f: 3};
    let y = &x.f;
    x = ~X {f: 4};  // Error reported here.
    *y
}


According to Debian Rust is still too experimental to be packaged.
http://web.mit.edu/rust-lang_v0.8/doc/tutorial-borrowed-ptr.html


servo is written in Rust.
https://github.com/mozilla/servo

There is very little use of "@", it's mostly  "&" and "~". Heck I didn't find any @ while casually browsing the code. It's like they are not using it at all.

I don't know Rust, it is the first day I look (read documentation) at it.

On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote:
>
> There is very little use of "@", it's mostly  "&" and "~". Heck I didn't find any @ while casually browsing the code. It's like they are not using it at all.
>

Similarly in current C++ std::shared_ptr is barely there while
std::unique_ptr is all over the place.

Am 11.05.2014 23:43, schrieb sclytrack:
> On Sunday, 11 May 2014 at 11:42:37 UTC, ponce wrote:
>> On Sunday, 11 May 2014 at 08:59:42 UTC, Walter Bright wrote:
>>>
>>> D also cannot be performance competitive with C++ if pervasive ARC is
>>> used and memory safety is retained. Rust is attempting to solve this
>>> problem by using 'borrowed' pointers, but this is unproven
>>> technology, see my reply to Manu about it.
>>
>> I work in a C++ shop and as I see it, resource management is becoming
>> a solved problem:
>>
>> - resource owners holds a std::unique_ptr<T> on them. Resource release
>> is taken care by C++ destructors normally. That means to be
>> exception-safe, each resource type must better have its class.
>> - resource users eventually "borrow" the resource by taking a raw
>> pointer out of the unique pointer. What Rust would do with lifetimes
>> here is ensure that the resource is still there since move semantics
>> seems pervasive in this language. In C++ we ensure the resource holder
>> outlive the users.
>> - std::shared_ptr is not needed with such constraints. This means no
>> cycles in the object graph. TBH I have yet to find a dependency scheme
>> that can't be done that way.
>>
>> When I use D I can't help but think that releasing resources feels
>> more manual and error-prone ("oops that resource should have been a
>> struct not a class" and such traps).
>>
>> I do not have huge concerns about D GC, but I would be glad to have
>> more support for owned pointers (ie. Unique!T in Phobos or better). I
>> have no idea how to make it safe ie. ensure the resource outlive its
>> users.
>
> I like this owner/unique, borrow thing.
>
> @ is managed (currently reference counted)
> ~ is owner
>       & is borrow
>
> fn example3() -> int {
>      let mut x = ~X {f: 3};
>      let y = &x.f;
>      x = ~X {f: 4};  // Error reported here.
>      *y
> }
>
>
> According to Debian Rust is still too experimental to be packaged.
> http://web.mit.edu/rust-lang_v0.8/doc/tutorial-borrowed-ptr.html
>
>
> servo is written in Rust.
> https://github.com/mozilla/servo
>
> There is very little use of "@", it's mostly  "&" and "~". Heck I didn't
> find any @ while casually browsing the code. It's like they are not
> using it at all.
>
> I don't know Rust, it is the first day I look (read documentation) at it.
>

Have you searched for RC<>() and GC<>() as well?

The @ is gone from Rust and replaced by library types.

--
Paulo

On Sunday, 11 May 2014 at 21:49:06 UTC, ponce wrote:
> On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote:
>>
>> There is very little use of "@", it's mostly  "&" and "~". Heck I didn't find any @ while casually browsing the code. It's like they are not using it at all.
>>
>
> Similarly in current C++ std::shared_ptr is barely there while
> std::unique_ptr is all over the place.

I guess that after burning their fingers with auto_ptr, people still have to realize that unique_ptr might be good to use.

On Sunday, 11 May 2014 at 22:06:55 UTC, Francesco Cattoglio wrote:
> On Sunday, 11 May 2014 at 21:49:06 UTC, ponce wrote:
>> On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote:
>>>
>>> There is very little use of "@", it's mostly  "&" and "~". Heck I didn't find any @ while casually browsing the code. It's like they are not using it at all.
>>>
>>
>> Similarly in current C++ std::shared_ptr is barely there while
>> std::unique_ptr is all over the place.
>
> I guess that after burning their fingers with auto_ptr, people still have to realize that unique_ptr might be good to use.

sorry, my bad, I read it reversed :D

11-May-2014 23:16, John Colvin пишет:
> On Sunday, 11 May 2014 at 18:18:41 UTC, Rainer Schuetze wrote:
>>
>>
>> On 11.05.2014 10:22, Benjamin Thaut wrote:
>>> Am 10.05.2014 19:54, schrieb Andrei Alexandrescu:
>>>>
>>>>> The next sentence goes on to list the advantages of RC (issues we have
>>>>> wrestled with, like destructors), and then goes on to say the recent
>>>>> awesome RC is within 10% of "the fastest tracing collectors".
>>>>> Are you suggesting that D's GC is among 'the fastest tracing
>>>>> collectors'? Is such a GC possible in D?
>>>>
>>>> I believe it is.
>>>>
>>>
>>> While it might be possible to implement a good GC in D it would require
>>> major changes in the language and its librariers. In my opinion it would
>>> be way more work to implement a propper GC than to implement ARC.
>>>
>>> Every state of the art GC requires percise knowdelge of _all_ pointers.
>>> And thats exactly what we currently don't have in D.
>>
>> I think most garbage collectors can work with a number of false
>> pointers. The referenced memory area has to be treated as pinned and
>> cannot be moved. Limiting the false pointers to stack and registers
>> seems like a compromise, though most of the stack could even be
>> annotated. Code for this does already exist in the debug info
>> generation, though I suspect stack tracing could be unreliable.
>>
>> Here's my current stance on the GC discussions:
>>
>> I agree that the current GC is pretty lame, even if it were precise.
>> "Stop-the-World" with complete tracing does not work for any
>> interactive application that uses more than a few hundred MB of
>> garbage collected memory (with or without soft-realtime requirements).
>> Other applications with larger allocation requirements are easily
>> dominated by collection time. Proposing to use manual memory
>> management instead is admitting failure to me.
>>
>> For a reasonable GC I currently see 2 possible directions:
>> Coventry
>> 1. Use a scheme that takes a snapshot of the heap, stack and registers
>> at the moment of collection and do the actual collection in another
>> thread/process while the application can continue to run. This is the
>> way Leandro Lucarellas concurrent GC works
>> (http://dconf.org/2013/talks/lucarella.html), but it relies on "fork"
>> that doesn't exist on every OS/architecture. A manual copy of the
>> memory won't scale to very large memory, though it might be compressed
>> to possible pointers. Worst case it will need twice as much memory as
>> the current heap.
>
> a) Can't we do our own specialised alternative, instead of doing
> something as heavyweight as fork?

Provided heap was allocated as one big mmap-ed region (or File mapping in Win32) it should be straightforward to remap it as Copy-on-Write. This would though reduce virtual memory available in half (if not more provided we'd want to leave some space for C's malloc).

Would be cool to find a way to the allocation of thread stacks... else we'd have to copy them while threads are frozen.



-- 
Dmitry Olshansky

On 5/11/2014 3:42 PM, Dmitry Olshansky wrote:
> Provided heap was allocated as one big mmap-ed region (or File mapping in Win32)
> it should be straightforward to remap it as Copy-on-Write. This would though
> reduce virtual memory available in half (if not more provided we'd want to leave
> some space for C's malloc).

This is not an issue for 64 bit machines. I don't think it would be a big problem if we have an improved GC for 64 bit machines only.

64 bits have other advantages for a GC - very few false pointers.

On 5/11/14, 2:49 PM, ponce wrote:
> On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote:
>>
>> There is very little use of "@", it's mostly  "&" and "~". Heck I
>> didn't find any @ while casually browsing the code. It's like they are
>> not using it at all.
>>
>
> Similarly in current C++ std::shared_ptr is barely there while
> std::unique_ptr is all over the place.

The right tally here would include bald pointers as well. Also, I'm quite surprised by the confidence of this assertion. -- Andrei