Java 9 Tech Preview Planned For Fedora 27

[ldo17]

http://benchmarksgame.alioth.debian.org/.

The mem columns say it all...

[Khrundel]

The mem columns say it all...

Yes, "everything is an object" and GC have costs. Each java object has header 8, 12 or 16 bytes (depending on architecture and reference compression settings) and also needs at least one reference to it (4 or 8 bytes). For simple datatypes as color or point that's a hell of an overhead.
By the way, if you compare with python, skipping examples with too low memory consumption (because jvm is heavier than cpython), you'll see that java consumes from 1/2 to 3x of corresponding python example. Assuming python's RCs work well, looks like GC is not main memory hog.

[DanLamb]

http://benchmarksgame.alioth.debian.org/.
When python program 20 times slower than java, nothing can save it. Unless you think JVM GC eats 90% of run time.

Python and Java both have many strong production uses cases. They also both have weaknesses.

I have tons of full time experience with both. I could list pros/cons of each, but that's probably a waste of time.

Python devs offload high performance pieces to some lower level library, which is a valid strategy.

[DanLamb]

The mem columns say it all...

Good point. I'm actually hoping that Java 9 will cut that down to reason. The compact strings feature of Java 9 should hopefully halve memory usage in these mini-benchmark apps. Then, hopefully the headline modularity feature should make less of the core JDK library be loaded when it isn't needed and help.

I'd love to see them show some benchmarks with the current feature complete JDK 9 builds, but they usually wait until final release and then just switch all Java benchmarks over.

[DanLamb]

The mem columns say it all...

Yes, memory use is an issue. I hope Java 9 helps with that. The compact strings feature should halve memory use in the types of mini-apps they are doing that are 100% string centric.

Then the modularity system will hopefully help avoid loading the bulk of the JDK that isn't used in the benchmark apps. If you look at the JDK 9 standard module graph, pretty much nothing is used other than the very basic core module. These benchmark apps don't do SQL, they don't do GUIs, no networking, no XML, just raw local text processing.

[ldo17]

I'm actually hoping that Java 9 will cut that down to reason.

Given that Javas 1-8 haven’t done so?

How do you think it will happen--will they adopt reference-counting at last?

[ldo17]

By the way, if you compare with python, skipping examples with too low memory consumption (because jvm is heavier than cpython), you'll see that java consumes from 1/2 to 3x of corresponding python example. Assuming python's RCs work well, looks like GC is not main memory hog.

Trouble is, none of those examples, that I can see, is running long enough for garbage collection to even become necessary.

Try comparing a test that will run memory-intensive for, say, an hour, and then see how the speed compares between Java, C and Python.

I suspect the Java version might not even complete the test without falling victim to the Dreaded OOM Killer...

[ldo17]

Oh, and I’ll just leave this here...

[DanLamb]

Given that Javas 1-8 haven’t done so?

Every version of every product adds stuff that all previous versions didn't have. That is such a petty comment to make.

How do you think it will happen--will they adopt reference-counting at last?

Reference counting is a form of garbage collection. I don't think that is the cutting edge or what people want. Go does standard mark/sweep.

This blog post I saw talks about the details of Java garbage collection vs Go's garbage collection:

https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e

[DanLamb]

Oh, and I’ll just leave this here...

EcmaScript is a great choice for a general teaching language.

That article says, ultra-obnoxious flame-war garbage like:

Many programmers who believe in open-source software would be happy to see Java wither and die if only to spite Oracle, a company seen as hostile to open source.

Programming langue choice is contentious. But they are also tools. There are times that one language makes sense over another. That article veers into cringe worthy emotional fanboy arguing for no good purpose.