3 ms·
Yep, and as a result of this, the JDK ecosystem is healthy as ever. N.b to those who have only written web or phone apps for a living -- GC latency isn't 'bad'
by iheartmemcache 10y ago
Yep, and as a result of this, the JDK ecosystem is healthy as ever. N.b to those who have only written web or phone apps for a living -- GC latency isn't 'bad' in most cases - unpredictable latency is what's bad. Having a deterministic upper-bound is what is important in the enterprise, on your aviation component regulating cabin pressure, on your SWIFT bank transfer.
Also, see the top comment here: https://news.ycombinator.com/item?id=11759762 https://news.ycombinator.com/item?id=11759762 for a JDK discussion against ref-counting, along with this [now incredibly old] paper https://www.cs.purdue.edu/homes/hosking/690M/urc-oopsla-2003.pdf https://www.cs.purdue.edu/homes/hosking/690M/urc-oopsla-2003...
(N.b. around the time that paper was published, I was in HFT. We used Azul C4 and it just fine to crush even with management taking their typical 30/3 fees. Though to be fair, this was when the easy pickin's were still there to be plucked. Don't underestimate how well good-ol' free Hotspot is now; we're not talking 1996 Jakarta days with Swing)
- pjmlp 10y agoOne of the reasons I always argue for GC is that I used Native Oberon, and also collect papers related to Xerox PARC and DEC research. Modern hardware would be a dream to any of those researchers doing systems programming in GC enabled languages. I only consider the biggest flaws of Java not adopting AOT from the beginning and the lack of value types. Now the JDK ecosystem needs to wait until Java 10, probably around 2020 or later, to get them.