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

31–40 of 88 posts

Re: From Java code to Java heap (2012)

#31

Post by jcdavis »

geodel wrote: post #20
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.

String is one that has changed pretty significantly - count and offset have been removed, only fields are hash and value now.

This means String.substring is no longer an O(1) method, but it saves 8 bytes per string which is huge, and also avoids some of the wierd corner case GC/memory issues that substring/StringBuilder caused by hanging on to the reference

Re: From Java code to Java heap (2012)

#32

Post by fauigerzigerk »

pron wrote: post #21
pjmlp wrote: post #16

Earlier quoted context omitted.

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.

It seems to me that companies that choose non-JVM languages (with the exception of .NET) for important server-side projects are those that have always opted for the flavor-of-the-month. Most of those using Go/Elixir/OCaml/Haskell today, are those that used PHP, Ruby, Python or Node yesterday, and are likely to pick something new tomorrow. All of these choices have deep, fundamental and serious problems -- both techni…

>All of these choices have deep, fundamental and serious problems -- both technical and environmental -- that are unlikely to ever be solved, but are all solved on the JVM.

The problems that the JVM solves are solved by other platforms as well, and they were in fact already "solved" by the time Java was invented. Java was the prototypical flavor of the month language at one point in time.

Programming language history sometimes seems pretty random. If Java hadn't hinted at the fantastic possibilities of the now completely defunct Applet technology, Smalltalk VMs might have captured the server-side with technologies very similar to what the JVM became many years later. They were arguably on the verge of doing that.

It's ironic that Applets failed because of unsolved problems with the JVM that remain largely unsolved to this day (such as insane memory usage and laggy startup).

And Java failing on the client side has created another problem unsolved by the JVM, which is code and skills sharing between client and server. That's one of the main reasons why node.js exists.

And the one problem with the JVM that is probably unsolvable forever is the influence of its authority-seeking users on software design. That's what makes the JVM environment so utterly broken. Its culture of excessive complexity.

I wouldn't dare to predict which flavor-of-the-month will fade and which one will dominate. It seems to be random and largely dependent on fantasies about future platforms unrelated to technological merit.

We could have stuck with Lisp and Fortran and we wouldn't be any worse off than we are today. There is very little progress in our industry when it comes to programming environments.

Re: From Java code to Java heap (2012)

#33

Post by gmarx »

breischl wrote: post #30
gmarx wrote: post #15

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?

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.

Re: From Java code to Java heap (2012)

#35

Post by pron »

geodel wrote: post #28
pron wrote: post #21

Earlier quoted context omitted.

It seems to me that companies that choose non-JVM languages (with the exception of .NET) for important server-side projects are those that have always opted for the flavor-of-the-month. Most of those using Go/Elixir/OCaml/Haskell today, are those that used PHP, Ruby, Python or Node yesterday, and are likely to pick something new tomorrow. All of these choices have deep, fundamental and serious problems -- both techni…

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.

Re: From Java code to Java heap (2012)

#36

Post by brown9-2 »

It seems really silly to compare the "search/insert/delete performance" of HashSet to HashMap to ArrayList to LinkedList, since the fundamental purpose of each class is different.

Not to mention that "search/insert/delete" are three separate operations with sometimes three different performance characteristics.

For instance it is incorrect to state that the insert/delete performance for LinkedList is O(n) - both are constant-time.

Re: From Java code to Java heap (2012)

#37

Post by pron »

fauigerzigerk wrote: post #32
pron wrote: post #21

Earlier quoted context omitted.

It seems to me that companies that choose non-JVM languages (with the exception of .NET) for important server-side projects are those that have always opted for the flavor-of-the-month. Most of those using Go/Elixir/OCaml/Haskell today, are those that used PHP, Ruby, Python or Node yesterday, and are likely to pick something new tomorrow. All of these choices have deep, fundamental and serious problems -- both techni…

>All of these choices have deep, fundamental and serious problems -- both technical and environmental -- that are unlikely to ever be solved, but are all solved on the JVM. The problems that the JVM solves are solved by other platforms as well, and they were in fact already "solved" by the time Java was invented. Java was the prototypical flavor of the month language at one point in time. Programming language history…

> The problems that the JVM solves are solved by other platforms as well, and they were in fact already "solved" by the time Java was invented. Java was the prototypical flavor of the month language at one point in time.

Perhaps, but they're not solved by any of the languages/platforms mentioned.

> Smalltalk VMs might have captured the server-side with technologies very similar to what the JVM became many years later. They were arguably on the verge of doing that.

Except that they were the same VMs (HotSpot was a Smalltalk VM). Smalltalk didn't lose; it just got repackaged as Java.

> And Java failing on the client side has created another problem unsolved by the JVM, which is code and skills sharing between client and server. That's one of the main reasons why node.js exists.

With that I agree, but JS has its own issues, and the other languages mentioned don't have it any easier in that regard.

> And the one problem with the JVM that is probably unsolvable forever is the influence of its authority-seeking users on software design. That's what makes the JVM environment so utterly broken. Its culture of excessive complexity.

Except that the JVM is by far the leading platform not only in conservative enterprises, but also among the thought-leaders and biggest technological innovators. I don't know if the JVM environment is "broken" or not, but it certainly isn't any more broken than any other platform for serious server-side software. As I said, for less-serious/smaller applications, Java and the JVM were not meant to be the first choices. We had VB and Delphi, then Python and Ruby, and now Node and whatever. It's the same market share, and I don't see evidence that the JVM is slipping.

Re: From Java code to Java heap (2012)

#38

Post by geodel »

jcdavis wrote: post #31
geodel wrote: post #20

Earlier quoted context omitted.

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.

String is one that has changed pretty significantly - count and offset have been removed, only fields are hash and value now. This means String.substring is no longer an O(1) method, but it saves 8 bytes per string which is huge, and also avoids some of the wierd corner case GC/memory issues that substring/StringBuilder caused by hanging on to the reference

Right. Java 9 will move from char[] to byte[] for String.value which will lead to further savings.

Re: From Java code to Java heap (2012)

#39

Post by pron »

pjmlp wrote: post #29
pron wrote: post #21

Earlier quoted context omitted.

It seems to me that companies that choose non-JVM languages (with the exception of .NET) for important server-side projects are those that have always opted for the flavor-of-the-month. Most of those using Go/Elixir/OCaml/Haskell today, are those that used PHP, Ruby, Python or Node yesterday, and are likely to pick something new tomorrow. All of these choices have deep, fundamental and serious problems -- both techni…

You are forgetting about the native desktop, IoT and mobile space, where besides Android's fork of Java, the language has lost its market. We have zero customers using Java, besides Android and legacy Swing applications on those areas. Otherwise customers are asking us instead for Qt/C++, .NET, Swift, Objective-C and Cordova/Ionic. With Microsoft adoption of Docker, and their Go sponsorship on Visual Studio Code, I h…

But Java was never "meant" to be a leader on the desktop; VB, Delphi and plenty of others have always had the lead. Whatever market share Java is losing, it is market share that it got due to market failure, and only held briefly. You're absolutely right about mobile, but the fragmentation there is such that no language/platform is the clear winner. Java's uncontested hegemony was short-lived, but even without it, it is an order of magnitude ahead of its closest competitor on the server side (with the exception of .NET). Everything else is just too fragmented to pick out a winner. Go is indeed an interesting challenge, but it has some fundamental issues that are serious roadblocks, while the JVM doesn't.

Let me put it this way: the war on server-side development is the JVM's to lose. Right now, it has some challenges (memory usage etc.) that are all solvable, if the important ones are recognized and addressed. Maybe they won't be, and someone else would step up and grab the lead. Maybe it'll be .NET; maybe it'll be Go; maybe JS. But right now, all alternative platforms are cannibalizing one another and competing for market share that has (almost) never been Java's much more than grabbing significant market share from the JVM.

Re: From Java code to Java heap (2012)

#40

Post by fauigerzigerk »

pron wrote: post #37
fauigerzigerk wrote: post #32

Earlier quoted context omitted.

>All of these choices have deep, fundamental and serious problems -- both technical and environmental -- that are unlikely to ever be solved, but are all solved on the JVM. The problems that the JVM solves are solved by other platforms as well, and they were in fact already "solved" by the time Java was invented. Java was the prototypical flavor of the month language at one point in time. Programming language history…

> The problems that the JVM solves are solved by other platforms as well, and they were in fact already "solved" by the time Java was invented. Java was the prototypical flavor of the month language at one point in time. Perhaps, but they're not solved by any of the languages/platforms mentioned. > Smalltalk VMs might have captured the server-side with technologies very similar to what the JVM became many years later…

>Perhaps, but they're not solved by any of the languages/platforms mentioned.

Go and Elixir do support concurrency/paralellism mechanisms that are not supported very well by the JVM. Go also solves the value type issues that cause the JVMs excessive memory usage. Code/skills sharing between client and server isn't supported by the JVM either (for web apps that is).

>Except that they were the same VMs (HotSpot was a Smalltalk VM)

Yes, but HotSpot is from 1999 whereas Java is came out in 1995 if I remember correctly. The initial Java VM was a bit of a throwback.

>I don't know if the JVM environment is "broken" or not, but it certainly isn't any more broken than any other platform for serious server-side software.

How do you define "serious"?

Post reply on HN