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

51–60 of 88 posts

Re: From Java code to Java heap (2012)

#51

Post by geodel »

pron wrote: post #35
geodel wrote: post #28

Earlier quoted context omitted.

Well if applications of future are to be developed and delivered as it is today Java will very likely remain primary choice. But with containerized deployment Java solutions looks rather heavyweight. Oracle/IBM/SAP know this. I think that's why work on Java EE 8 is kind of stalled. Java GC/ memory shortcomings become visible when companies like Netflix push it to limit e.g http://techblog.netflix.com/2016/05/applicat…

Go's advantage when it comes to GC is very temporary. HotSpot's GCs are more advanced, and Go has the upper hand only thanks to value types, which are coming to Java. Go will not come close to catching up by then. I think that containerized deployment is likely to evolve and change at a much faster pace than development platforms, so it's really hard to tell which approaches would fit where.

Java release cycle is ~3yrs so Java 10 will be roughly expected in 2020/21 time frame. And at that point larger ecosystem like Apache etc will start taking advantage of value type. So it is like 6-8 years from now which I would not characterize as very temporary. Also this is assuming Go committer from now onwards just sit and do nothing about performance improvements which again seems quite unlikely.

Java has 15 year head start on Go and if a newer Go GC beats very mature hotspot GC it could either mean Hotspot advantage is largely in theory or it has reached its peak performance and there is not much scope to improve further.

Re: From Java code to Java heap (2012)

#52

Post by x0x0 »

gmarx wrote: post #33
breischl wrote: post #30

Earlier quoted context omitted.

As with everything performance related, it depends. I do server-side work as well, but I've seen cases where it matters. eg, somebody got overly "OO-happy" with a response object and managed to take something that should've been one object with 8 fields and instead made a graph of 8 object with a total of 12 fields (4 of them repeated), wasting ~400 bytes each IIRC. When you're creating one of those for each request…

What did it save you server-wise and how long did it take to identify and make the change? Also, did you discover this as part of a performance problem investigation or was it something you saw upfront and nipped in the bud before it became a problem. I agree it sounds like poor design. I instinctively simplify whatever info is going to be sent from the server.

Generally when building servers on top of a jvm, it's a good idea to be able to capture eg 1m requests, replay them, and monitor your memory allocation / gc as part of quality tests. If you create nests of objects in java, it quickly gets expensive, both in terms of net memory and gc costs. One common place this happens is parsing json/xml; use thrift or protobufs instead.

If you are eg building an ad server that is supposed to sustain some XX thousand requests per second, you want to also monitor eg eden, survivor, tenured, and promotions. Bump pointer allocation and gc is very fast -- normally faster even than manual memory management -- as long as almost nothing survives. The problem is if some objects start accidentally living past requests, stuff goes boom fast.

Re: From Java code to Java heap (2012)

#53

Post by PDoyle »

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)

This article is super old. Those options are now default, and the overhead is much smaller. (I think even in 2012, we already had 1-word headers.)

Re: From Java code to Java heap (2012)

#54

Post by PDoyle »

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.

J9 has had one-word headers for years now. I think this article was already out of date in 2012 when it was published.

Re: From Java code to Java heap (2012)

#56

Post by [deleted] »

pjmlp wrote: post #49
pron wrote: post #42

Earlier quoted context omitted.

> Go and Elixir do support concurrency/paralellism mechanisms that are not supported very well by the JVM. Nope. Tooting my own horn here, but the Quasar library on the JVM has both models to the T, performs on-par with Go and blows Erlang/Elixir out of the water in its own game. > Go also solves the value type issues that cause the JVMs excessive memory usage True, but not only is that solvable, it is actually being…

> True, but not only is that solvable, it is actually being solved on the JVM as we speak I am looking forward for it, but with Brian Goetz speaking about Java 10+ (note the plus) and Oracle not having a programming language culture, I am not sure they will ever happen in the near future. IBM also doesn't talk any more about Packed Objects and I don't know if anyone is really paying attention to Gil efforts promoting…

[deleted]

Re: From Java code to Java heap (2012)

#57

Post by bitmapbrother »

pjmlp wrote: post #49
pron wrote: post #42

Earlier quoted context omitted.

> Go and Elixir do support concurrency/paralellism mechanisms that are not supported very well by the JVM. Nope. Tooting my own horn here, but the Quasar library on the JVM has both models to the T, performs on-par with Go and blows Erlang/Elixir out of the water in its own game. > Go also solves the value type issues that cause the JVMs excessive memory usage True, but not only is that solvable, it is actually being…

> True, but not only is that solvable, it is actually being solved on the JVM as we speak I am looking forward for it, but with Brian Goetz speaking about Java 10+ (note the plus) and Oracle not having a programming language culture, I am not sure they will ever happen in the near future. IBM also doesn't talk any more about Packed Objects and I don't know if anyone is really paying attention to Gil efforts promoting…

>IBM also doesn't talk any more about Packed Objects

Of course they do. You're just not looking in the right place.

http://mail.openjdk.java.net/pipermail/panama-spec-experts/

Re: From Java code to Java heap (2012)

#58

Post by pron »

geodel wrote: post #51
pron wrote: post #35

Earlier quoted context omitted.

Go's advantage when it comes to GC is very temporary. HotSpot's GCs are more advanced, and Go has the upper hand only thanks to value types, which are coming to Java. Go will not come close to catching up by then. I think that containerized deployment is likely to evolve and change at a much faster pace than development platforms, so it's really hard to tell which approaches would fit where.

Java release cycle is ~3yrs so Java 10 will be roughly expected in 2020/21 time frame. And at that point larger ecosystem like Apache etc will start taking advantage of value type. So it is like 6-8 years from now which I would not characterize as very temporary. Also this is assuming Go committer from now onwards just sit and do nothing about performance improvements which again seems quite unlikely. Java has 15 yea…

Go's GC doesn't beat HotSpot's GCs. It just has less work to do, and this is being fixed in Java. In any event, I think the biggest potential threat to Java isn't Go (which has some fundamental issues that are very hard to fix) or .NET, but the JS ecosystem, which may become the universal VM.

Re: From Java code to Java heap (2012)

#59

Post by pron »

fauigerzigerk wrote: post #47
pron wrote: post #42

Earlier quoted context omitted.

> Go and Elixir do support concurrency/paralellism mechanisms that are not supported very well by the JVM. Nope. Tooting my own horn here, but the Quasar library on the JVM has both models to the T, performs on-par with Go and blows Erlang/Elixir out of the water in its own game. > Go also solves the value type issues that cause the JVMs excessive memory usage True, but not only is that solvable, it is actually being…

>Tooting my own horn here, but Quasar on the JVM has both models to the T, performs on-par with Go and blows Erlang/Elixir out of the water in its own game. If that is so then kudos to you. >it is actually being solved on the JVM as we speak Right, it is being worked on and it will be worked on for many years to come before it gets released I'm afraid. >This isn't any worse than any language that isn't JS Yes, but Ja…

> Right, it is being worked on and it will be worked on for many years to come before it gets released I'm afraid.

Three or four, most likely. That's not a long time at all.

> Yes, but JavaScript VMs do exist, they are serious competition for the JVM, also, as you say, as a compilation target, which makes it even worse for the JVM. The importance of "runs in the browser" is hard to overstate. And then there is WebAssembly on the horizon.

I agree. If I were to pick the biggest threat to the JVM, it wouldn't be .NET or Go, but the JS ecosystem -- including wasm, which, although low-level at this time and more resembling LLVM, may grow to be a universal high-level VM one day.

> Many platforms have that covered.

I think almost none do.

> By that standard, Java could never have gotten to the place it is in now.

Java (and by that I mean mostly the JVM) were designed after careful analysis of market needs. This kind of analysis is only available to certain players, so it pretty much puts OCaml, Haskell and other academic languages out of the race. This leaves JS, Go, Erlang and .NET. Go seems unwilling to really study the market, so it will achieve success among the novelty seekers, who will then move on to the next thing; Erlang -- which has an amazing, inspiring design -- has no advantage over the JVM, and is at such a huge disadvantage in terms of resources, that the chance of it ever catching up is close to zero. This leaves .NET and JS, both with plenty of resources and a lot of industry involvement, and they are the only candidates that at this time appear to be able to unseat Java.

Re: From Java code to Java heap (2012)

#60

Post by pjmlp »

bitmapbrother wrote: post #57
pjmlp wrote: post #49

Earlier quoted context omitted.

> True, but not only is that solvable, it is actually being solved on the JVM as we speak I am looking forward for it, but with Brian Goetz speaking about Java 10+ (note the plus) and Oracle not having a programming language culture, I am not sure they will ever happen in the near future. IBM also doesn't talk any more about Packed Objects and I don't know if anyone is really paying attention to Gil efforts promoting…

>IBM also doesn't talk any more about Packed Objects Of course they do. You're just not looking in the right place. http://mail.openjdk.java.net/pipermail/panama-spec-experts/

I know that list.

1 to 2 emails per month, for something that might eventually come in Java 10 or later isn't talking about it.

Post reply on HN