On Tuesday, 18 November 2014 at 02:39:48 UTC, Walter Bright wrote:
> On 11/17/2014 1:57 PM, deadalnix wrote:
>> 2. I'm not sure if that is enough to make it work. It is worth
>> investigating. It is gonna be much more limited than what I have
>> in mind.
>
> There was a lot of skepticism initially when I proposed that ref be a storage class rather than a type constructor, but it turned out that the problems were resolvable and the end design was an unqualified win. So I think we can do this - at a minimum we need to exhaust the possibility.

ref only make sense at interface boundary. That is not the same
thing.

On Saturday, 15 November 2014 at 20:13:47 UTC, deadalnix wrote:
> On Saturday, 15 November 2014 at 12:52:33 UTC, Ola Fosheim Grøstad wrote:
>> Thanks for the link! I agree ML has some interesting work done for it, but they make some assumptions:
>>
>> 1. low portion of mutable objects
>>
>> 2. small heap fits in per-core-cache (<256KiB on Haswell).
>>
>> So the small heap is basically a region allocator that caches allocations that are likely to die, cutting down on the more costly effort to update the big heap. But I am not sure if that fits system level programming, that is more typical for functional programming…
>
> The small heap do not apply for us. We can't reproduce that part of the GC in D. However, the big heap part of the strategy would fit D's immutable heap very nicely.

Maybe, but immutable in ML means that two different immutable objects are 100% indistinguishable if they have the same value. Quite often you have a cluster of objects (that could be an isolate) that are periodically immutable. I assume what is most interesting is whether it is immutable between two collections, and not whether it is mutable throughout the lifespan?

There are two points in the powerpoint that sticks out though:

* «trade collection “quality” for level of synchronization - allow large amounts of floating
garbage»

* «trade collection “simplicity” for level of synchronization - complicated algorithm (not to
mention correctness proof)»

And also this:

«Root enumeration
* Raise a flag to signal beginning of marking
* shade globals
* ask mutators to shade roots
* wait until all mutators answered
* meanwhile - start scanning and marking»

Does this mean that you need all threads (which I presume are the mutators) to be in an eventloop in order to collect?


Online version of the slides:
http://s0.docspal.com/files/processed/64/6863864-yusxlrni/doligez.pdf

On Tuesday, 18 November 2014 at 20:34:01 UTC, Ola Fosheim Grøstad
wrote:
> Does this mean that you need all threads (which I presume are the mutators) to be in an eventloop in order to collect?
>

What you need is for each thread to provide you a list of roots.
You can start tracing while having an incomplete list of roots,
so the level of concurrency allowed is high.

As for the immutability thing, here is how it goes. When you
compile to native, you can either do write barrier all the time,
via writing point using a function call in the runtime. The
second option is to not do it and use memory protection to trap
write.

Option 1 is usually preferred by VM that can swicth
implementation of methods when collecting, so you pay a moderate
cost and only when you collect. But if you compile AOT, you
always pay that price and it is not very interesting.

Optin 2 is WAY more expensive and will trap even write to value,
not only pointers. If it expensive, it is only expensive when it
traps. That mean it is a very interesting choice for code
compiled ahead of time and manipulating immutable data. This is
very interesting in the case of ML, where the compiler sometime
choses to mutate, but only as an optimization, and very rarely on
object that reach the big heap, as if the object is long lived
enough to reach that heap, most likely the compiler can't prove
it is unique and thus mutable.

The same strategy seems like the obvious winner for D's immutable
heap as well as part of the shared heap that do not contain
mutable pointers.

What would be the next step to keep this effort going forward ?
A POC implementation would be a lot of work but it would also
help people detect corner cases or unsuspected interaction with
some features of the language.

Finally got a look at your proposal. While I do agree with many initial statements and, specifically, proposal for heap segregation, proposed semantics of `owned` does leave me skeptical. It is effectively a more refined/mature approach to "cooking of immutables" concept and Marc proposal, while being more complicated semantic-wise, allows for much more than that.

On Thursday, 4 December 2014 at 14:23:13 UTC, Dicebot wrote:
> Finally got a look at your proposal. While I do agree with many initial statements and, specifically, proposal for heap segregation, proposed semantics of `owned` does leave me skeptical. It is effectively a more refined/mature approach to "cooking of immutables" concept and Marc proposal, while being more complicated semantic-wise, allows for much more than that.

I don't think this is solving the same problem as Marc's proposal so I'm not sure how comparing them make sense. Marc's proposal is about manipulating data without having ownership. This defines ownership.

This proposal add some complexity, but I do think this is a winner. Right now we have various type qualifier (mutable, const, immutable, shared, const shared, inout, inout shared). This come at a cost, and, ultimately, as the proposal interact with this, you want to compare the total complexity with the total benefit.

In one case, you have 7 qualifier. You get a mostly safe language out of them.
With he proposal, you have 8 qualifiers. You get a safe language out of it + many opportunities to optimize + added expressiveness (ie interaction of GC and no gc code, ownership transfers, safe reference counting, extension of possibilities in @nogc code in a similar fashion as weakly pure allow for extra expressiveness in pure code).

If you allow me for a non politically correct metaphor, would you buy a 1$ condom with an hole in it or a 1.14$ one that do not ?

On Thursday, 4 December 2014 at 23:22:04 UTC, deadalnix wrote:
> I don't think this is solving the same problem as Marc's proposal so I'm not sure how comparing them make sense. Marc's proposal is about manipulating data without having ownership. This defines ownership.

Indeed. But both combined add too much complexity to be feasible and thus we need to decide what problems are more important to solve. I think one from Marc has wider application while elements of yours can be more suitable as hidden implementation detail. Though now there is also DIP69 and I need to seriously shake them all through my head before having any true opinion :P

> This proposal add some complexity, but I do think this is a winner. Right now we have various type qualifier (mutable, const, immutable, shared, const shared, inout, inout shared). This come at a cost, and, ultimately, as the proposal interact with this, you want to compare the total complexity with the total benefit.

I respectfully can't agree that shared qualifier truly exists in current language implementation. Thus perspective is a bit different. Also const/inout don't actually tell anything about how underlying data is managed and serve as secondary utility qualifiers.