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

21–30 of 88 posts

Re: From Java code to Java heap (2012)

#21

Post by pron »

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.

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 technical and environmental -- that are unlikely to ever be solved, but are all solved on the JVM. Those problems are sometimes obscured by the novelty and promise of the shiny alternative, and take a while to be felt among those who always opt for the new thing, but they are invariably discovered later on, and by that time something newer comes along, whose problems are yet unapparent. The problems are there because unlike Java and the JVM (and Fortran, COBOL, C and Rust), those platforms were not developed after careful consideration of the industry's needs (Erlang/Elixir is a different story, and, indeed its fundamental problems are more environmental than technical).

In addition, in smaller/less-critical projects, Java was an accidental leader in a short period of time where the competition disappeared and Java itself was novel, but it was never "supposed" to be there to begin with. VB and Delphi were very popular choices early on. I'd estimate that even when Java was the shiny new thing, VB, Delphi and other rapid-development languages had a larger share of the market than Go, Node, Ruby, Python, Haskell and OCaml combined today. And frankly, I don't see companies developing en masse large-scale applications in C++14. Unless you have very specific needs, there's just no reason to go there and pay a higher development cost, and if you do have those needs, you're probably already there.

In large corporations (including trendy ones, like Google, Amazon, Netflix, Twitter and many more, let alone more conservative ones) the JVM still reigns supreme, with competition lagging far, far behind. I'm not saying it won't eat into the JVM's market share -- although they're mostly cannibalizing one another -- but I don't see any potential leader in the pack. It's possible that there won't be one, with many sharing the cake.

So I think that (again, with the notable exception of .NET) the non-JVM market is composed of novelty-seeking organizations and a share that wasn't Java's to begin with, but accidentally was for a short while (the two segments intersect).

Re: From Java code to Java heap (2012)

#22

Post by kpil »

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.

One benefit is the extremely large set of 3rd party libraries and tools. It's hard to catch up outside the mainstream bread and butter stuff.

Also, finding experienced developers, devops, etc.

While Kotlin is interesting, and can use java code, maybe it's a little too small and have less battle tested toolchains so java probably feels like a slightly safer bet for large projects and conservative organisations.

Re: From Java code to Java heap (2012)

#23

Post by whack »

As someone who used to be a hardware engineer, I found Figure 1 in the first section surprising. All modern OS run processes on independent virtual memory spaces, in order to ensure that processes don't collide with one another, or with the OS itself. But if figure 1 is to be believed, the kernel shares the same address space as the process. Is this a mistake on the part of the writer?

[1] http://www.cs.utexas.edu/users/witchel/372/lectures/15.Virtu...

[2] https://en.wikipedia.org/wiki/Virtual_address_space

Re: From Java code to Java heap (2012)

#24

Post by dr_rust »

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.

You may be right, i don't know.

Tracking a cause of OutOfMemoryError recently (we maintain several applications written in Java at my day job), i've observed that most data-structures have a size very different if empty or not.

Re: From Java code to Java heap (2012)

#25

Post by markokrajnc »

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

"... but Android Java is not 100%" => Android N will use OpenJDK.

Re: From Java code to Java heap (2012)

#26

Post by pjmlp »

markokrajnc wrote: post #25
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.…

"... but Android Java is not 100%" => Android N will use OpenJDK.

Android N will use selected parts of the OpenJDK, it isn't 100% Java 8 compliant.

And with Marshmallow having 7.5% market share[1] how long do you think will take for developers even to start caring about Java 8 support on Android N?

[1] https://developer.android.com/about/dashboards/index.html

Re: From Java code to Java heap (2012)

#27

Post by kevhito »

whack wrote: post #23

As someone who used to be a hardware engineer, I found Figure 1 in the first section surprising. All modern OS run processes on independent virtual memory spaces, in order to ensure that processes don't collide with one another, or with the OS itself. But if figure 1 is to be believed, the kernel shares the same address space as the process. Is this a mistake on the part of the writer? [1] http://www.cs.utexas.edu/us…

No, it's not a mistake. Each process has it's own virtual address space, but part of that space is typically used to map operating system code and data. The reserved part is anywhere from a quarter to a half on a 4GB 32-bit system (I have no idea on a 64bit). Those pages are marked kernel-only. The upper half to three-quarters will be different for each process.

One reason for this is so that you can easily trap to the kernel (for an interrupt, a system call, an exception, etc.) without changing the page tables at all -- you just change the cpu mode bit.

Re: From Java code to Java heap (2012)

#28

Post by geodel »

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…

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/application-data-caching...

They specifically mention:

> ... The decision to use Go was deliberate, because we needed something that had lower latency than Java (where garbage collection pauses are an issue) and is more productive for developers than C, while also handling tens of thousands of client connections. Go fits this space well.

Re: From Java code to Java heap (2012)

#29

Post by pjmlp »

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…

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 have started to see some Java consulting companies on my area to add Go on their services list.

Most Java deployments that I have to deal with on server side are still on Java 1.5 - 1.7, RichFaces and the occasional Websphere.

Re: From Java code to Java heap (2012)

#30

Post by breischl »

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 and handling 200k requests/sec it adds up to a lot of memory. That means a lot of time spent in the GC, which means a lot of GC pauses, not to mention effects on memory bandwidth, locality, and processor cache usage.

All else equal, using less memory is faster and more scalable than using more memory. Java programmers seem to frequently forget that object references do have a cost associated with them.

Tangentially, those complex object graphs also make (de-)serialization much harder than it needs to be. Requests & responses should be as simple as possible!

Post reply on HN