For the JVM. Not for ART, especially when using full ahead-of-time compilation rather than interpreter / JIT modes.
-
-
Java start-up time has to do with the JIT compiler, not GC. GC would usually reduce start-up time by delaying work.
2 replies 0 retweets 0 likes -
Replying to @CopperheadOS @fugueish
There are lots of reasons Java is slow not related to JIT. And lots of reasons GC is slow or bloated indep. of Java.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @fugueish
GC can have decent latency, higher throughput than non-GC with around ~2-3x memory usage for a much leaner language.
2 replies 0 retweets 0 likes -
Replying to @CopperheadOS @fugueish
2-3x memory usage is huge when memory is a big portion of your power consumption.
1 reply 0 retweets 0 likes -
And worst-case stop-the-world is always > one refresh period, i.e. you ALWAYS have user-visible UI-response hiccups.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @fugueish
Not all GC works that way. The throughput oriented ones do.
1 reply 0 retweets 0 likes -
Replying to @CopperheadOS @fugueish
I've never seen a defensible claim that you can do realtime-compatible GC. Always turns out to be smoke & mirrors.
2 replies 0 retweets 1 like -
You either run out of mem in cases where you shouldn't, or you freeze for a long time in some cases.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @fugueish
Look at Go, then. They're shipping it. The latency is good enough for many uses and keeps getting better.
2 replies 0 retweets 0 likes
Yeah, they're impressed at themselves for getting stop-the-world down to 100us on high-end hardware... *sigh*
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.