3 ms·
>For example, poorly designed GCs don't scale well on multiple processors. You could very well be paying for a single shared allocator lock or have a young gene
by runT1ME 16y ago
>For example, poorly designed GCs don't scale well on multiple processors. You could very well be paying for a single shared allocator lock or have a young generation shared across multiple packages.
Java's GC is anything but poorly designed, and it definitely scales to spades.
>When are your threads idle? Can you produce log events for when your threads block on locks to see how often your threads are live versus sitting around?
A good profiler should be able to show this. I've had a lot of luck with Yourkit, but others may work just as well.
- larsberg 16y agoPoorly designed was a harsh choice of words. A better way of putting it would be "not yet optimized for single program execution processor counts > 6 or so." The allocation wall (http://portal.acm.org/citation.cfm?id=1639949.1640116 http://portal.acm.org/citation.cfm?id=1639949.1640116) is something a lot of folks are seeing in practice across a variety of virtual machine-based languages (including Java) when scaling to about 8 cores.
- runT1ME 16y agoHrm, interesting. I would have thought the way allocation is done with threadlocal variables negate a lot of the scaling for allocs, but I could be wrong. Do you have a direct link to the PDF, or mind putting it somewhere? I don't have an ACM login.
- larsberg 16y agoSorry, but unfortunately I can't. The authors are permitted to put it online (where scholar.google and CiteSeerX usually immediately find them) but in this case they don't appear to have done so.