On Wednesday, 21 January 2015 at 10:00:21 UTC, deadalnix wrote:
1. less efficient codegen + restrictions related to FFI
No.
How would that work? You cannot trace pointers that stay in
registers. You also cannot do precise unwinding of FFI stacks.
3. intermittent pauses
I think you don't quite get what concurrent is about.
Parallel: running simultaneously
Concurrent: parallel and/or interleaving
C# use intermittent pauses/parallel
https://msdn.microsoft.com/en-us/library/ee787088(v=vs.110).aspx#concurrent_garbage_collection
4. random cache pollution
If you have a multicore (and you have one) no.
Multicore won't help on cache level 3. (hyper-threading cores
share cache too)
Inconvenient if you try to get the most out of the hardware.
This is all the contrary. As you may have noticed, most memory
allocation intensive benchmark in Java tend to outperform their
C++ counter part.
Malloc is not fast. If you want performance you use O(1)
allocators/deallocators. Bogus benchmarks to make Java look good
are not convincing.
