Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From Java code to Java heap (2012)

ibm.com

Post reply on HN
Print view View original

11–20 of 88 posts

Re: From Java code to Java heap (2012)

#11

Post by Longhanks »

pjmlp wrote: post #10
needusername wrote: post #8

Earlier quoted context omitted.

> 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.…

Also, what advantages, except existing code bases, does Java provide to Kotlin, Go, Swift, Rust? For about any use case I can imagine a better choice than Java.

Also, concerning the recent events (Google vs. Oracle), I think every new project might want to triple check if they really want to use a product from someone like Oracle.

Re: From Java code to Java heap (2012)

#12

Post by pron »

Longhanks wrote: post #11
pjmlp wrote: post #10

Earlier quoted context omitted.

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.…

Also, what advantages, except existing code bases, does Java provide to Kotlin, Go, Swift, Rust? For about any use case I can imagine a better choice than Java. Also, concerning the recent events (Google vs. Oracle), I think every new project might want to triple check if they really want to use a product from someone like Oracle.

Kotlin is a JVM language, and doesn't really compete with Java (the two are "friendly"). Rust is a low-level language which is much better suited than the JVM to memory-restricted environments, but JVM languages (including Java) are much easier (therefore cheaper) to develop, so are a better choice for server-side applications. Go and Java are indeed very similar, but I find that Go is better for smaller programs and Java is better for larger ones (due to amazing monitoring, polyglotism, dynamic code loading etc.).

Re: From Java code to Java heap (2012)

#13

Post by virmundi »

Longhanks wrote: post #11
pjmlp wrote: post #10

Earlier quoted context omitted.

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.…

Also, what advantages, except existing code bases, does Java provide to Kotlin, Go, Swift, Rust? For about any use case I can imagine a better choice than Java. Also, concerning the recent events (Google vs. Oracle), I think every new project might want to triple check if they really want to use a product from someone like Oracle.

A lot of tooling. Eclipse just works. You don't have to use Intellij. Spring makes most things a breeze. Maven handles dependencies and complex builds easily. A lot of the language issues disappear with the right, battle tested tooling.

Re: From Java code to Java heap (2012)

#14

Post by jcdavis »

needusername wrote: post #7

It 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.

Only on 32 bit IIRC, headers are 12 byte on 64 bit with CompressedOops (the default for heaps http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee275...

Re: From Java code to Java heap (2012)

#15

Post by gmarx »

In my work I rarely find this sort of thing relevant. It's much more important to make sure you don't have object references lying around. I mostly do server stuff now. Maybe this kind of optimization is still important for devices?

Re: From Java code to Java heap (2012)

#16

Post by pjmlp »

pron wrote: post #12
Longhanks wrote: post #11

Earlier quoted context omitted.

Also, what advantages, except existing code bases, does Java provide to Kotlin, Go, Swift, Rust? For about any use case I can imagine a better choice than Java. Also, concerning the recent events (Google vs. Oracle), I think every new project might want to triple check if they really want to use a product from someone like Oracle.

Kotlin is a JVM language, and doesn't really compete with Java (the two are "friendly"). Rust is a low-level language which is much better suited than the JVM to memory-restricted environments, but JVM languages (including Java) are much easier (therefore cheaper) to develop, so are a better choice for server-side applications. Go and Java are indeed very similar, but I find that Go is better for smaller programs and…

Yeah, Rust is not the real adversary.

The real adversaries are Objective-C, Go, Swift, .NET Native, C++14, OCaml, Haskell and even node.js.

Monitoring tools similar to VisualVM will come.

Nowadays my Java code is either targeted at Android or maintenance of existing enterprise code. Other than that we aren't using it for greenfield projects.

Re: From Java code to Java heap (2012)

#17

Post by the8472 »

pjmlp wrote: post #16
pron wrote: post #12

Earlier quoted context omitted.

Kotlin is a JVM language, and doesn't really compete with Java (the two are "friendly"). Rust is a low-level language which is much better suited than the JVM to memory-restricted environments, but JVM languages (including Java) are much easier (therefore cheaper) to develop, so are a better choice for server-side applications. Go and Java are indeed very similar, but I find that Go is better for smaller programs and…

Yeah, Rust is not the real adversary. The real adversaries are Objective-C, Go, Swift, .NET Native, C++14, OCaml, Haskell and even node.js. Monitoring tools similar to VisualVM will come. Nowadays my Java code is either targeted at Android or maintenance of existing enterprise code. Other than that we aren't using it for greenfield projects.

> Monitoring tools similar to VisualVM will come.

Well, in java-land visualvm already exists and is more of an entry-level/free tool with its big brothers available if it should prove insufficient.

Java tooling is amazing, I miss it in most other languages.

Re: From Java code to Java heap (2012)

#18

Post by nalllar »

the8472 wrote: post #5
dmichulke wrote: post #3

Most 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}

They also can't be enabled with >32GiB heaps.

Re: From Java code to Java heap (2012)

#19

Post by the8472 »

nalllar wrote: post #18
the8472 wrote: post #5

Earlier quoted context omitted.

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}

They also can't be enabled with >32GiB heaps.

They can if you increase the object alignment, but that's generally not advisable and should only be done when measurements show a benefit.

Re: From Java code to Java heap (2012)

#20

Post by geodel »

dr_rust wrote: post #9

Can 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 :(

I think the object layout is not changed. I just ran jol tool for HashMap and size looks similar to what is mentioned in the article.
Post reply on HN