What's wrong with D's templates?

Walter Bright newshound1 at digitalmars.com
Fri Dec 25 09:40:27 PST 2009


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.


>> 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.


> 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.

> 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!



More information about the Digitalmars-d mailing list