191–200 of 286 posts
Earlier quoted context omitted.
I don't know about that. I coded in UCSD-P quite a bit (and played a few games written in it, Wizardry on the Apple 2 anyone?). But UCSD-Pascal never reached a tiny fraction of the audience that Turbo Pascal did.
Turbo Pascal certainly had more users, but it was never "run anywhere".
Are you talking about the host OS and the fact that Turbo Pascal was Windows only, as opposed to Pascal UCSD which was a VM?
Earlier quoted context omitted.
That's not always true. Most of the time when Java uses a ton of memory it's because people use the default memory settings. If you tell Java to use up to 90% of system RAM, it will. Garbage collection is expensive so it will delay until memory is depleted. This is a different GC design than V8 and Go, which use older collector designs with high overhead. They need to collect very frequently because their stop the wo…
> This is a different GC design than V8 and Go, which use older collector designs with high overhead. I think this information is a bit dated. Go has a highly advanced concurrent collector with very low pause times (~1-100μs). V8 also has incremental marking, concurrent marking, and parallel compaction. Its pause times are more like 100-1000μs. V8's GC has been tuned more and more to save memory (i.e. smaller heaps)…
Uh, most of the rant about Go GC below is out of date, they made some huge improvements from 2016-now. I'm leaving it up because someone replied to it
Unless something has changed in the last year or two, Go's GC is similar to Java's old CMS collector which is being deprecated.
Go's GC is non generational and non compacting, both hallmarks of modern GC algorithms. It's not a modern "moving" collector. It also has several stop the world phases. It's basically a design from the 70's. The GC uses old simple algorithms because the team was under a time crunch when it was developed. This may have changed, but that's how it was in 2018-2019 timeframe.
The pause times are short because GC runs very frequently. It has to because performance with large amounts of garbage is quite bad. This results in significant GC CPU overhead.
I don't know much about V8 collector besides that it is generational and compacting, so more modern than Go. But it's still a "stop the world" design. In that regard it's still closest to Javas old CMS collector.
Javas new collectors, ZGC and Shenandoah, both have near constant time stop the world phases. You can collect terabytes of garbage with only a few milliseconds pause. In V8 or Go, this would be many seconds pause time as the mark phase is "stop the world" in both.
You can find benchmarks that show one way or the other, but in badly behaving or allocation heavy applications, Java's new collectors or older G1 will perform far better. V8 and Go are dishonest about their GC performance by showing average pause times with high collection frequency. The important GC cycles are the long ones, so you really want to measure worse case pause time under load.
Under heavy load Go's design falls over. It's not compacting, not generational, and the mark phase pauses the application. IMO, it's just not a good GC. V8 is better, it is generational and compacting, but mark phase is still STW. Java's ZGC isn't generational but importantly, the mark and sweep phases don't stop execution. No matter how big your heap is and how much garbage, your GC pauses will be short
Earlier quoted context omitted.
> How do you find a reasonably small Xmx that doesn't lead to OutOfMemoryError exceptions? That's tough to figure out. In new versions of Java, I think 14+, if you use ZGC collector it will return unused memory to the OS. Memory options vary depending on collector, but new versions of ZGC support "soft max" heap size and uncommit. Together it might be close to what you're looking for https://malloc.se/blog/zgc-softma…
Thanks for the advice. I'm stuck on 11 until the next LTS release but I'll definitely be trying ZGC next year. (ZGC is in 11 but still marked experimental, and I'm conservative about making changes.)
Newer versions of ZGC support class unloading and have some other performance optimizations
Earlier quoted context omitted.
> the model cannot scale to real software needs. And somehow it is still widely used within Google, Facebook, Amazon, Twitter...
Most of those companies are not writing one-thread-per-request servers, they write non-blocking / async IO Java.
But for a service which needs to handle 500 concurrent requests at maximum and doesn't have to deal with TLS anymore it will be fine. And there's enough of those services out there.
A lot of the Java code in bigger companies is also written based on older frameworks like earlier versions of Servlet and J2EE. Those programs will also not make any use of async mechnanisms and prefer a simple programming model instead.
Earlier quoted context omitted.
> This is a different GC design than V8 and Go, which use older collector designs with high overhead. I think this information is a bit dated. Go has a highly advanced concurrent collector with very low pause times (~1-100μs). V8 also has incremental marking, concurrent marking, and parallel compaction. Its pause times are more like 100-1000μs. V8's GC has been tuned more and more to save memory (i.e. smaller heaps)…
I don't agree with your pause time estimates. Most collectors are fast with small amounts of garbage in a small application. It's high allocation rates where GC time becomes a problem, and I don't see anything about Go or V8 designs to prevent very bad worst-case pause times. Uh, most of the rant about Go GC below is out of date, they made some huge improvements from 2016-now. I'm leaving it up because someone replie…
> ... In V8 or Go, this would be many seconds pause time as the mark phase is "stop the world" in both.
Like I said before, your information is outdated. V8 has both incremental and concurrent marking. I even mentioned it in my comment, but apparently you didn't read that either. V8 only stops the world for semispace evacuation and compaction. It doesn't compact the entire old generation at once, but decides on a per-page basis.
For Go's GC, I am going by public information presented by one of its primary designers, Rick Hudson, who has since retired.
You can argue with his slides if you want. https://blog.golang.org/ismmkeynote
Java's new GCs sound fantastic! It's great for the field in general. However, I would encourage you to spend less time misrepresenting other people's work and making up numbers.
Earlier quoted context omitted.
I'm not saying Java code isn't very portable, and there are some notable exceptions (the IntelliJ/JetBrains products always are first to come to mind) of successful cross platform Java client apps. But much of the original late 90s hype about Java was its cross platform nature, especially in the browser, but Java applets and other in-browser Java technologies were never popular (consider GMail and other GWT apps were…
Ironically if Java developers had used the built in DOM APIs instead of the Applet canvas crap, we probably would have had great SPAs a lot earlier.
i wonder if it was because at the time, the different DOM api in each browser was so immature, that to unify it into a single api is too big a task. The applet+blackbox region for rendering is the easiest MVP. Of course, with hindsight, that turned out to be a piece of crap.
Earlier quoted context omitted.
That's not always true. Most of the time when Java uses a ton of memory it's because people use the default memory settings. If you tell Java to use up to 90% of system RAM, it will. Garbage collection is expensive so it will delay until memory is depleted. This is a different GC design than V8 and Go, which use older collector designs with high overhead. They need to collect very frequently because their stop the wo…
All OK except when you need the same level of performance for those 0.001% of requests when the GC kicks in and takes the response time outside acceptable limits. Due to this reason alone, my company is planning to move off a popular Java based API gateway and to a C++ envoy side car implemented service mesh. And I am wondering if this is really worth it.
In my limited tests I never saw a GC pause over 5ms. I was basically hammering a Spring Boot application with HTTP load tester.
Earlier quoted context omitted.
Ironically, while Java was the original "write once, run anywhere" language, it never succeeded in that regard (e.g. browser applets were never popular). Ironically, I believe Javascript has. I was pretty much exclusively a Java programmer for the first decade and a half of my career, before moving to Node and TypeScript. I don't think I could ever go back at the point. Most importantly, this is my first time where t…
> Ironically, while Java was the original "write once, run anywhere" language, it never succeeded in that regard (e.g. browser applets were never popular). Ironically, I believe Javascript has. It completely succeeded in that! Java (well JVM) developers today can - Write code on any of Windows/Linux/macOS - Deploy that code on any of Windows/Linux/macOS Not a lot of language/platforms can claim to this amount of succ…
Earlier quoted context omitted.
Shitty Android.
Android moved past the Java restriction ten years ago. First by adding their own features to the JDK, and today simply by making Kotlin the main language to program in on Android. Android is completely unshackled from Java today. Android is compeltely