On 05/12/2014 06:37 PM, Walter Bright wrote:
> On 5/12/2014 5:15 AM, Timon Gehr wrote:
>> On 05/12/2014 10:54 AM, Walter Bright wrote:
>>> On 5/11/2014 10:57 PM, Marco Leise wrote:
>>>> Am Sun, 11 May 2014 17:50:25 -0700
>>>> schrieb Walter Bright <newshound2@digitalmars.com>:
>>>>
>>>>> As long as those pointers don't escape. Am I right in that one cannot
>>>>> store a
>>>>> borrowed pointer into a global data structure?
>>>>
>>>> Right, and that's the point and entirely positive-to-do™.
>>>
>>> This means that a global data structure in Rust has to decide what
>>> memory allocation scheme its contents must use,
>>
>> Global variables are banned in Rust code outside of unsafe blocks.
>
> Global can also mean assigning through a reference passed as a parameter.
>

Do you mean the table is not actually global but passed by parameter, or that the global table is accessed in unsafe code and then passed by parameter or something else?

Andrei Alexandrescu:

> I, too, felt the need of onGC() - actually preGC() - in my allocators implementation.
> ...
> A hook that nulls all freelist heads just as the collection process starts would be helpful.

How is this going to help increase tracing precision of unions (and Algebraic built on top of unions)?

Bye,
bearophile

On 5/12/14, 12:59 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> I, too, felt the need of onGC() - actually preGC() - in my allocators
>> implementation.
>> ...
>> A hook that nulls all freelist heads just as the collection process
>> starts would be helpful.
>
> How is this going to help increase tracing precision of unions (and
> Algebraic built on top of unions)?

How did I give the impression it has anything to do with unions? -- Andrei

Andrei Alexandrescu:

> How did I give the impression it has anything to do with unions? -- Andrei

OK, so yours is not an answer to my proposal, nor related to it.

Bye,
bearophile

On 5/12/2014 12:36 PM, Timon Gehr wrote:
> Do you mean the table is not actually global but passed by parameter,

Yes.

But note that the distinction between the two is often blurry. Under the hood on some systems, global data is accessed via the equivalent of a hidden parameter.

On Mon, 12 May 2014 14:14:28 -0400, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:

> On Monday, 12 May 2014 at 17:52:18 UTC, Walter Bright wrote:
>> On 5/12/2014 7:46 AM, Steven Schveighoffer wrote:
>>> pointing at it is roughly 1/256. This problem is just about eliminated with
>>> 64-bit pointers.
>
> Not generally true. This presumes that the heap is not in the lower region of the address space and that you don't use 64 bit ints on the stack.

I was thinking in terms of purely a random number happening to point at heap data. Practically speaking, I don't know the true likelihood based on the heap address scheme of 64-bit OSes, but I know that we always have a complainer who will try and do an array-append test on 32-bit code, and end up exhausting memory unexpectedly.

-Steve

Le 12/05/2014 19:14, Dicebot a écrit :
> On Monday, 12 May 2014 at 17:03:41 UTC, Manu via Digitalmars-d wrote:
>> But D is *so close*... and I like it! >_<
>>
>> I have to say that this discussion has certainly left me somewhat
>> intrigued by Rust though.
>> I've never given it a fair go because I find the syntax so distasteful
>> and deterring.
>> I wonder if there's a market for a rust fork that re-skin's the
>> language ;)
>
> Right now D has practical benefit of being more stable and library rich.
> But switching to Rust eventually does seem tempting as I find
> foundations of their type system much closer to my beliefs about "good
> coding practices".
>
> It lacks any good static reflection though. And this stuff is damn
> addictive when you try it of D caliber.

All compile time things of D are marvelous.
This with the compile time and the language less error prone make me want D.
I am not sure I need safety so much. It's nice but not mandatory for any of my projects. The only one which has to be safe is DQuick.

On Mon, 12 May 2014 13:52:20 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 5/12/2014 7:46 AM, Steven Schveighoffer wrote:
>> It doesn't matter where the false pointers are. The largest issue with false
>> pointers is not how many false pointers there are. It only matters how large the
>> block is that it "points" at. The larger your blocks get, the more likely they
>> are "pointed" at by the stack. On 32-bit systems, allocate 1/256th of your
>> memory space (i.e. 16.5MB), and the likelihood of random data on the stack
>> pointing at it is roughly 1/256. This problem is just about eliminated with
>> 64-bit pointers.
>
> Generally, it is a bad idea to allocate such large blocks on the GC heap. GC's work best when the size of the objects being allocated is very small relative to the size of the heap space.
>
> Fortunately, it's a mathematical inevitability that large allocations relative to the GC size are rare, and so it isn't much of a pain to handle them manually.

The issue arises when one allocates such a large block for temporary use repeatedly, but expects it to be collected between allocations. The consequences are extremely disastrous.

The workaround is simply to keep it around, but that's not always a scalable solution.

>> And in fact, even if it's forbidden, "requires" is too strong a word -- there is
>> no static or runtime prevention of this.
>
> It's still forbidden. Andrei wrote a template that will verify this at runtime, but I don't recall its name.

Can you cite the spec where it says it's forbidden? Forgotten templates are not a convincing argument.

Regardless, Java can use a moving GC, and allows self references. The idea that self references prevent a moving GC is simply false. If you think about it a bit, you will understand why.

-Steve

On Mon, 12 May 2014 17:32:09 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:


>
> The workaround is simply to keep it around, but that's not always a scalable solution.

Sorry, actually you can free it. That's the correct workaround.

-Steve

On Monday, 12 May 2014 at 21:22:09 UTC, Steven Schveighoffer wrote:
> On Mon, 12 May 2014 14:14:28 -0400, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:
>
>> On Monday, 12 May 2014 at 17:52:18 UTC, Walter Bright wrote:
>>> On 5/12/2014 7:46 AM, Steven Schveighoffer wrote:
>>>> pointing at it is roughly 1/256. This problem is just about eliminated with
>>>> 64-bit pointers.
>>
>> Not generally true. This presumes that the heap is not in the lower region of the address space and that you don't use 64 bit ints on the stack.
>
> I was thinking in terms of purely a random number happening to point at heap data. Practically speaking, I don't know the true likelihood based on the heap address scheme of 64-bit OSes, but

Wicked topic. In AMD64 mode hi-mem is usually reserved for kernel etc. Traditionally the unixy heap grew from low towards high addresses:

http://en.wikipedia.org/wiki/Sbrk

But that is legacy. I think mmap is it… :-P And layout is randomized to reduce the effect of buffer overflow etc.

:-(

> I know that we always have a complainer who will try and do an array-append test on 32-bit code, and end up exhausting memory unexpectedly.

Uhuh. Not focusing on precise collection gets ugly.