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