From Java code to Java heap (2012)
1–10 of 88 posts
Re: From Java code to Java heap (2012)
#2very detailed and interesting read!
Re: From Java code to Java heap (2012)
#3Most useful info:
If you run the 64 bit JRE and have memory problems, use the flags
- Xcompressedrefs
- XX:+UseCompressedOops
for a decent 35-45% reduction in memory use.
The rest is well-known stuff (use primitives, use arrays with fixed size, ...)
Still, the numbers are quite interesting (and the overhead quite scary)
Re: From Java code to Java heap (2012)
#4As I move into other languages like Go and Swift, would love to see breakdowns of how they store objects in memory comparable to Java.
Re: From Java code to Java heap (2012)
#5Most useful info: If you run the 64 bit JRE and have memory problems, use the flags - Xcompressedrefs - XX:+UseCompressedOops for a decent 35-45% reduction in memory use. The rest is well-known stuff (use primitives, use arrays with fixed size, ...) Still, the numbers are quite interesting (and the overhead quite scary)
On hotspot ergonomics automatically turn those options on as long as your max heap is
$ java -Xmx31G -XX:+PrintFlagsFinal 2>&1 | grep UseCompressed
bool UseCompressedClassPointers := true {lp64_product}
bool UseCompressedOops := true {lp64_product}Re: From Java code to Java heap (2012)
#6As I move into other languages like Go and Swift, would love to see breakdowns of how they store objects in memory comparable to Java.
In any case better, thanks to value types support and layout control.
Somehow I would like they would have focused on value types and reified generics for Java 9 instead of jigsaw and postponing them to Java 10+.
Re: From Java code to Java heap (2012)
#7It has to be noted that on HotSpot the object header is only two words not three words like on J9. Basically Flags and Locks fit into one word on HotSpot whereas they use two words on J9.
Re: From Java code to Java heap (2012)
#8As I move into other languages like Go and Swift, would love to see breakdowns of how they store objects in memory comparable to Java.
In any case better, thanks to value types support and layout control. Somehow I would like they would have focused on value types and reified generics for Java 9 instead of jigsaw and postponing them to Java 10+.
> Somehow I would like they would have focused on value types and reified generics for Java 9 instead of jigsaw and postponing them to Java 10+.
I hear you. Cost-benefit wise Jigsaw doesn't look attractive to me. To be honest I would have preferred Java 9 in the fall of 2016 without Jigsaw.
Re: From Java code to Java heap (2012)
#9Can someone add 2012 in the title,
Most of the OpenJDK collections have been rewritten during the Java 8 timeframe, so the values are out of date :(
Re: From Java code to Java heap (2012)
#10Earlier quoted context omitted.
In any case better, thanks to value types support and layout control. Somehow I would like they would have focused on value types and reified generics for Java 9 instead of jigsaw and postponing them to Java 10+.
> Somehow I would like they would have focused on value types and reified generics for Java 9 instead of jigsaw and postponing them to Java 10+. I hear you. Cost-benefit wise Jigsaw doesn't look attractive to me. To be honest I would have preferred Java 9 in the fall of 2016 without Jigsaw.
Java is getting lots of new competition from languages that have proper support for value types, have layout control and have AOT available for free on their reference compilers.
On the desktop it already lost to .NET, Qt and HTML 5.
On the mobile it might reign in Android, but Android Java is not 100% Java and I don't see Google improving the language, in case Oracle stops doing it now that they had another setback.
They went silent on future of JEE and IBM is now doing lots of Swift and Go support, while making J9 language agnostic.
So I really don't care about jigsaw.