What's wrong with D's templates?

[grauzone]

Walter Bright wrote:
> grauzone wrote:
>> Also, it's bad how inter-thread communication will trigger GC runs, 
> 
> No, it won't. Allocation may trigger a GC run.
> 
>> which will stop all threads in the process for a while. Because you 
>> have no choice but to allocate your immutable messages from the shared 
>> heap.
> 
> It all depends. Value messages are not allocated. Immutable data 
> structures can be pre-allocated.

As soon as you have slightly more complex data like a simple string, the 
trouble starts.

> 
>>> This does not make the gc inherently unusable. Java, for example, 
>>> uses only one shared gc. It must, because Java has no concept of 
>>> thread local.
>>
>> What does Java matter here? Java was designed twenty years aho, when 
>> multicore wasn't an issue yet. D2 is designed *now* with good 
>> multicore support in mind.
> 
> It matters because Java is used a lot in multithreaded applications, and 
> it is gc based. The gc is not a disastrous problem with it.

For one, Java has an infinitely better GC implementation than D. Yeah, 
this isn't a problem with the concept or the language specification, but 
it matters in reality.

There's no way a shared GC is ever going to be scalable with multicores. 
If I'm wrong and it can be made scalable, I'd like to see it. Not just 
in theory, but in D.

> 
>> Also I'm not sure if you're right here. Java has a generational 
>> copying GC, and although I don't know Sun Java's implementation at 
>> all, I'm quite sure the younger generation uses an entirely thread 
>> local heap. In the normal case, it shouldn't need to get a single lock 
>> to allocate memory. Just an unsynchronized pointer incrementation to 
>> get the next memory block (as fast as stack allocation). If a memory 
>> block "escapes" to the older generation (the GC needs to detect this 
>> case anyway), the memory can be copied to a shared heap.
> 
> Getting a memory block can be done with thread local pools, but the 
> pools are from *shared* memory and when a collection cycle is done, it 
> is done across all threads and shared memory.
> 
>> This means old dumb Java will completely smash your super multicore 
>> aware D2.
> 
> I think you're confusing allocating from a thread local cache from the 
> resulting memory being thread local. The latter doesn't follow from the 
> former.

I didn't say thread local allocation couldn't improve the situation, but 
the problem is still there: a GC costs too much. You'll be escape the 
situation a while (e.g. by adding said thread local pools), but I think 
eventually you'll have to try something different.

I think having thread local heaps could be a viable solution, especially 
because the D2 type system is *designed* for it. All data is thread 
local by default, and trying to access it from other threads is 
forbidden and will break stuff. We have shared/immutable to allow 
inter-thread accesses. There will be *never* be pointers to 
non-shared/mutable between different thread. This just cries for 
allocating "normal" data on isolated separate per-thread heaps.

I was just wondering what you'd do about immutable data. But OK, you're 
not going this way. What a waste. We can end the discussion here, sorry 
for the trouble.

>> At least if someone wants to allocate memory... oh by the way, no way 
>> to prevent GC cycles on frequent memory allocations, even if the 
>> programmer knows that the memory isn't needed anymore: it seems manual 
>> memory managment is going to be deemed "evil". Or did I hear wrong 
>> that "delete" will be removed from D2?
>>
>> By the way... this reminds me of Microsoft's Singularity kernel: they 
>> achieve full memory isolation between processes running in the same 
>> address, space without extending the type system with cruft like 
>> immutable. Processes can communicate like Erlang threads using the 
>> actor model.
> 
> Erlang is entirely based on immutability of data. The only "cruft" they 
> got rid of was mutability!

You could understand your argument as "having both is cruft". Maybe D2 
would be better if we removed all mutable types?