On Sunday, 11 May 2014 at 17:36:44 UTC, Manu via Digitalmars-d wrote:
> On 12 May 2014 02:38, Marco Leise via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> Am Sun, 11 May 2014 14:52:50 +1000
>> schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:
>>
>>> On 11 May 2014 05:39, H. S. Teoh via Digitalmars-d
>>> <digitalmars-d@puremagic.com> wrote:
>>> > On Sat, May 10, 2014 at 09:16:54PM +0200, Xavier Bigand via Digitalmars-d wrote:
>>> >>  - Same question if D migrate to ARC?
>>> >
>>> > I highly doubt D will migrate to ARC. ARC will probably become
>>> > *possible*, but some language features fundamentally rely on the GC, and
>>> > I can't see how that will ever be changed.
>>>
>>> Which ones are incompatible with ARC?
>>
>> Pass-by-value slices as 2 machine words
>
> 64bit pointers are only 40-48 bits, so there's 32bits waste for an
> offset... and if the base pointer is 32byte aligned (all allocated
> memory is aligned), then you can reclaim another 5 bits there... I
> think saving an arg register would probably be worth a shift.
> 32bit pointers... not so luck :/
> video games consoles though have bugger all memory, so heaps of spare
> bits in the pointers! :P


I thought x86_64 pointers are sign extended? or does that just apply to real memory pointers and not virtual memory pointers?

Am Mon, 12 May 2014 03:36:34 +1000
schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:

> On 12 May 2014 02:38, Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > Am Sun, 11 May 2014 14:52:50 +1000
> > schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:
> >
> >> On 11 May 2014 05:39, H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >> > On Sat, May 10, 2014 at 09:16:54PM +0200, Xavier Bigand via Digitalmars-d wrote:
> >> >>  - Same question if D migrate to ARC?
> >> >
> >> > I highly doubt D will migrate to ARC. ARC will probably become *possible*, but some language features fundamentally rely on the GC, and I can't see how that will ever be changed.
> >>
> >> Which ones are incompatible with ARC?
> >
> > Pass-by-value slices as 2 machine words
> 
> 64bit pointers are only 40-48 bits, so there's 32bits waste for an
> offset... and if the base pointer is 32byte aligned (all allocated
> memory is aligned), then you can reclaim another 5 bits there... I
> think saving an arg register would probably be worth a shift.
> 32bit pointers... not so luck :/
> video games consoles though have bugger all memory, so heaps of spare
> bits in the pointers! :P

And remember how people abused the high bit in 32-bit until kernels were modified to support the full address space and the Windows world got that LARGE_ADDRESS_AWARE flag to mark executables that do not gamble with the high bit.

On the positive side the talk about Rust, in particular how reference counted pointers decay to borrowed pointers made me think the same could be done for our "scope" args. A reference counted slice with 3 machine words could decay to a 2 machine word "scoped" slice. Most of my code at least just works on the slices and doesn't keep a reference to them. A counter example is when you have something like an XML parser - a use case that D traditionally (see Tango) excelled in. The GC environment and slices make it possible to replace string copies with cheap slices into the original XML string.

-- 
Marco

On Sunday, 11 May 2014 at 20:18:23 UTC, luminousone wrote:
> I thought x86_64 pointers are sign extended? or does that just apply to real memory pointers and not virtual memory pointers?

With typed slices you can use one 64 bit base pointer and two 32 bit indexes instead of two pointers.

On Monday, 12 May 2014 at 04:22:21 UTC, Marco Leise wrote:
> On the positive side the talk about Rust, in particular how
> reference counted pointers decay to borrowed pointers made me
> think the same could be done for our "scope" args. A reference
> counted slice with 3 machine words could decay to a 2 machine
> word "scoped" slice. Most of my code at least just works on the
> slices and doesn't keep a reference to them. A counter example
> is when you have something like an XML parser - a use case
> that D traditionally (see Tango) excelled in. The GC
> environment and slices make it possible to replace string
> copies with cheap slices into the original XML string.

Rust also has a solution for this: They have lifetime annotations. D's scope could be extended to support something similar:

    scope(input) string getSlice(scope string input);

or with methods:

    struct Xml {
        scope(this) string getSlice();
    }

scope(symbol) means, "this value references/aliases (parts of) the value referred to by <symbol>". The compiler can then make sure it is never assigned to variables with longer lifetimes than <symbol>.

On Sunday, 11 May 2014 at 05:16:26 UTC, Paulo Pinto wrote:
> This is what java.lang.ref.ReferenceQueue are for in Java, but one needs to be a GC expert on how to use it, otherwise it will hinder the GCs work.

I think all memory-partitioning-related performance requires expert knowledge. If people care about performance and reliability they have to accept that they cannot blindly use abstractions or throw everything into the same bag.

Java is probably a good example of how unrealistic it is to have a general programming language that does reasonable well in most domains. The outcome has not been "everybody under the Sun umbrella", but a wide variety of Java runtime-solutions and special systems.

Le 12/05/2014 06:26, Marco Leise a écrit :
> Am Mon, 12 May 2014 03:36:34 +1000
> schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:
>
>> On 12 May 2014 02:38, Marco Leise via Digitalmars-d
>> <digitalmars-d@puremagic.com> wrote:
>>> Am Sun, 11 May 2014 14:52:50 +1000
>>> schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:
>>>
>>>> On 11 May 2014 05:39, H. S. Teoh via Digitalmars-d
>>>> <digitalmars-d@puremagic.com> wrote:
>>>>> On Sat, May 10, 2014 at 09:16:54PM +0200, Xavier Bigand via Digitalmars-d wrote:
>>>>>>   - Same question if D migrate to ARC?
>>>>>
>>>>> I highly doubt D will migrate to ARC. ARC will probably become
>>>>> *possible*, but some language features fundamentally rely on the GC, and
>>>>> I can't see how that will ever be changed.
>>>>
>>>> Which ones are incompatible with ARC?
>>>
>>> Pass-by-value slices as 2 machine words
>>
>> 64bit pointers are only 40-48 bits, so there's 32bits waste for an
>> offset... and if the base pointer is 32byte aligned (all allocated
>> memory is aligned), then you can reclaim another 5 bits there... I
>> think saving an arg register would probably be worth a shift.
>> 32bit pointers... not so luck :/
>> video games consoles though have bugger all memory, so heaps of spare
>> bits in the pointers! :P
>
> And remember how people abused the high bit in 32-bit until
> kernels were modified to support the full address space and
> the Windows world got that LARGE_ADDRESS_AWARE flag to mark
> executables that do not gamble with the high bit.
>
> On the positive side the talk about Rust, in particular how
> reference counted pointers decay to borrowed pointers made me
> think the same could be done for our "scope" args. A reference
> counted slice with 3 machine words could decay to a 2 machine
> word "scoped" slice. Most of my code at least just works on the
> slices and doesn't keep a reference to them. A counter example
> is when you have something like an XML parser - a use case
> that D traditionally (see Tango) excelled in. The GC
> environment and slices make it possible to replace string
> copies with cheap slices into the original XML string.
>
I don't really understand why there is no parser with something like slices in a language without GC. It's not possible to put the array to a more globally place, then the parser API will use 2 indexes instead of the buffer as parameter?

On Saturday, 10 May 2014 at 19:17:02 UTC, Xavier Bigand wrote:
> My concerns as Dlang user are :
>  - Even if GC is the solution, how long I need suffer with destructor's issues (calls order)?

What issues do you have with destructors and how they affect you?

>  - When we will able to see a performant GC implementation can satisfy someone like Manu :) ? Months, years, a decade?

Neither GC nor C heap will satisfy Manu's requirements. When it comes to shooters, the only way is to not allocate and write accurate code, even in C++. Even substitution of allocator won't help him, if the code relies on GC in a non-trivial way.

On Monday, 12 May 2014 at 21:54:51 UTC, Xavier Bigand wrote:
> I don't really understand why there is no parser with something like slices in a language without GC. It's not possible to put the array to a more globally place, then the parser API will use 2 indexes instead of the buffer as parameter?

Slices are counterproductive if you want to provide standard-compliant xml implementation, i.e. unescape strings. It also requires more memory to hold entire xml document and can't collect nodes, which became unused. Usually xml parsers use a string table to reuse all repetitive strings in xml, reducing memory requirements.

Am Mon, 12 May 2014 08:44:51 +0000
schrieb "Marc Schütz" <schuetzm@gmx.net>:

> On Monday, 12 May 2014 at 04:22:21 UTC, Marco Leise wrote:
> > On the positive side the talk about Rust, in particular how reference counted pointers decay to borrowed pointers made me think the same could be done for our "scope" args. A reference counted slice with 3 machine words could decay to a 2 machine word "scoped" slice. Most of my code at least just works on the slices and doesn't keep a reference to them. A counter example is when you have something like an XML parser - a use case that D traditionally (see Tango) excelled in. The GC environment and slices make it possible to replace string copies with cheap slices into the original XML string.
> 
> Rust also has a solution for this: They have lifetime annotations. D's scope could be extended to support something similar:
> 
>      scope(input) string getSlice(scope string input);
> 
> or with methods:
> 
>      struct Xml {
>          scope(this) string getSlice();
>      }
> 
> scope(symbol) means, "this value references/aliases (parts of) the value referred to by <symbol>". The compiler can then make sure it is never assigned to variables with longer lifetimes than <symbol>.

Crazy shit, now we are getting into concepts that I have no idea of how well they play in real code. There are no globals, but threads all create their own call stacks with independent lifetimes. So at that point lifetime annotations become interesting.

-- 
Marco

On 13 May 2014 14:39, Kagamin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Saturday, 10 May 2014 at 19:17:02 UTC, Xavier Bigand wrote:
>>
>> My concerns as Dlang user are :
>>  - Even if GC is the solution, how long I need suffer with destructor's
>> issues (calls order)?
>
>
> What issues do you have with destructors and how they affect you?
>
>
>>  - When we will able to see a performant GC implementation can satisfy
>> someone like Manu :) ? Months, years, a decade?
>
>
> Neither GC nor C heap will satisfy Manu's requirements. When it comes to shooters, the only way is to not allocate and write accurate code, even in C++. Even substitution of allocator won't help him, if the code relies on GC in a non-trivial way.

I'm not quite sure what you're saying, but I don't think it's quite as stringent as you suggest, at least, not anymore. We so try to minimise allocations, but some dynamic memory usage is just a modern reality. There is only a single requirement I see for automatic memory management to be practical, and it is very simple; time associated with whatever memory management needs to be fine-grained and evenly distributed. It needs to be amortised in some way.

This obviously lends itself to eager-freeing systems like ARC. If a GC can be made that is reasonably nonintrusive; like one that is decently concurrent, ideally incremental in some way, maybe has split pools, where a high-frequency/small-allocation/temporary pool (ie, runtime temp data, closures, strings) may clean up very quickly without resulting in full memory scans... maybe it's possible. I don't know. The problem is, it's been years, nobody seems to know how to do it. It's still not clear that would be acceptable, and I have no reason to believe such a GC would be higher performance than ARC anyway... but I'm more than happy to be surprised, if someone really thinks it can be done.

The other topic is still relevant to me too however (and many others).
We still need to solve the problem with destructors.
I agree with Andrei, they should be removed from the language as they
are. You can't offer destructors if they don't get called. And the
usefulness of destructors is seriously compromised if you can't rely
on them being executed eagerly. Without eager executed destructors, in
many situations, you end up with effective manual releasing the object
anyway (*cough* C#), and that implies manually maintaining knowledge
of lifetime/end of life and calling some release. I see memory
management as a moot offering as soon as that reality exists.
If we do end out with a GC that is somehow acceptable (I'm still
skeptical), then this discussion about what to do with destructors is
still ongoing.

Do we ARC just those objects that have destructors like Andrei suggested? It's a possibility, I can't think of any other solution. In lieu of any other solution, it sounds like we could very well end up with ARC tech available one way or another, even if it's not pervasive, just applied implicitly to things with destructors.