3 ms·

It's been a while since I've done work in Java, but I'm pretty sure the GC is not to blame for this. Java uses a concurrent mark and sweep GC. The concurrent pa

by lars 15y ago

It's been a while since I've done work in Java, but I'm pretty sure the GC is not to blame for this. Java uses a concurrent mark and sweep GC. The concurrent part means it does not pause the world while it's collecting. So as mbell says, it has to do with the UI frameworks. But I don't think it has to do with whether or not the UI code is written in C either. In the UI frameworks I've used for both Python and Ruby, you could write slow interpreted code that would run on the UI thread. The key thing was you tended not to do it, because the frameworks didn't encourage you to do so. The problem is that Java frameworks make it easy to for example do IO on the UI thread, whereas the other frameworks make it hard. Threading is relatively hard to get right in any of these languages, so the choices made by the framework authors really matter. Another thing contributing to Java being perceived as being slow is the long boot time of the JVM. (It used to be slow at least, don't know if it still is.)

mbell 15y ago
> It's been a while since I've done work in Java, but I'm pretty sure the GC is not to blame for this. Java uses a concurrent mark and sweep GC. Part of the problem is that the default GC is not the ConcMarkSweep collector in most installations but rather its the parallel "stop the world" GC that is optimized for throughput, not latency. For web applications (or anything with latency issues) step one is almost always to modify your JVM opts to enable the CMS collector. Unfortunately even the ConcMarkSweep collector can have issues. Its not that hard to create a workload that it can't handle resulting in your app slowing eating through all available heap space because the collector can't keep up ultimately forcing a full collection which on large heaps can be devastating, think 60 to 120 second pauses. The G1 collector, which is no longer considered experimental in Java 7 is 'better' and you can specify a maximum pause time, but it can still run into situations where it has to force a full GC and there are situations where the CMS collector is still better.

by lars 15y ago

mbell 15y ago

> It's been a while since I've done work in Java, but I'm pretty sure the GC is not to blame for this. Java uses a concurrent mark and sweep GC. Part of the problem is that the default GC is not the ConcMarkSweep collector in most installations but rather its the parallel "stop the world" GC that is optimized for throughput, not latency. For web applications (or anything with latency issues) step one is almost always to modify your JVM opts to enable the CMS collector. Unfortunately even the ConcMarkSweep collector can have issues. Its not that hard to create a workload that it can't handle resulting in your app slowing eating through all available heap space because the collector can't keep up ultimately forcing a full collection which on large heaps can be devastating, think 60 to 120 second pauses. The G1 collector, which is no longer considered experimental in Java 7 is 'better' and you can specify a maximum pause time, but it can still run into situations where it has to force a full GC and there are situations where the CMS collector is still better.