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?
