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

41–50 of 88 posts

Re: From Java code to Java heap (2012)

#41

Post by swsieber »

brown9-2 wrote: post #36

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…

I'm not sure how LinkedList insert/delete performance isn't O(n) where n is the list length - care to shed some light?

Are you assuming you have a node in the linked list? That might be constant, but the standard is to remove by index, and that's O(n).

Re: From Java code to Java heap (2012)

#42

Post by pron »

fauigerzigerk wrote: post #40
pron wrote: post #37

Earlier quoted context omitted.

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

> 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 solved on the JVM as we speak, and will be released long before Go will have caught up. OTOH, Go has some serious issues that are unlikely to ever be solved (its reliance on source-code instrumentation and lack of support for dynamic code manipulation; this has been demonstrated to be of great value for many server software systems).

> Code/skills sharing between client and server isn't supported by the JVM either (for web apps that is).

This isn't any worse than any language that isn't JS. On the JVM you have Kotlin, Clojure and Scala, all also compile to JS, and those are just the leading options.

> How do you define "serious"?

Critical software that is required to serve for a decade or more, and whose development costs exceed, say, one man-decade. .NET is pretty much Java's only serious competition there.

Re: From Java code to Java heap (2012)

#43

Post by breischl »

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.

It was something written by a different team, so it was committed by the time I saw it. But I thought it looked bad immediately. Profiling later showed that it was a problem spot, and changing it showed decent improvement.

Re: From Java code to Java heap (2012)

#44

Post by brown9-2 »

swsieber wrote: post #41
brown9-2 wrote: post #36

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…

I'm not sure how LinkedList insert/delete performance isn't O(n) where n is the list length - care to shed some light? Are you assuming you have a node in the linked list? That might be constant, but the standard is to remove by index, and that's O(n).

Ah, I was assuming foolishly that we were talking about removing or inserting only at the head or the tail. All the more reason to be more detailed in a writeup than simply "Performance: O(n)" :)

Re: From Java code to Java heap (2012)

#45

Post by aardvark179 »

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.

Also Go's GC doesn't move objects, which makes the whole problem a lot easier as long as heap fragmentation doesn't end up biting you badly in the end.

Re: From Java code to Java heap (2012)

#46

Post by taco_emoji »

brown9-2 wrote: post #36

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…

Insertion and removal will always require traversal first since the LinkedList's node class is private.

Re: From Java code to Java heap (2012)

#47

Post by fauigerzigerk »

pron wrote: post #42
fauigerzigerk wrote: post #40

Earlier quoted context omitted.

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

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

>Critical software that is required to serve for a decade or more, and whose development costs exceed, say, one man-decade.

Many platforms have that covered. Your arguments in favor of the most widely used platform seem a bit tautological at times. By that standard, Java could never have gotten to the place it is in now.

Re: From Java code to Java heap (2012)

#48

Post by ww520 »

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…

It's pretty common to map the kernel memory address to the same fixed range in the virtual memory address space of every process. Typically the kernel portion resides on the higher range of the memory space. For the 32-bit 2/2 split setup, 0GB-2GB is reserved for user mode and 2GB-4GB for kernel. With 1/3 split, 0GB-3GB for user and 3GB-4GB for kernel.

This makes it easy to work on memory shared between user mode and kernel mode code since it's the same address space. Buffer passed from user mode to kernel mode is just a matter of passing down the virtual memory address pointer, no need to copy. The kernel code accessing it just accesses the lower range of the virtual memory space.

The kernel code mapped to the same fixed range in every process also makes it easy to call kernel routine from user mode. SysCall just elevates privilege to be in kernel mode and jumps to the kernel routine at the exact same address in every process. You can think of the kernel as a special library got "linked" into every process at the exact same location, along with all its data.

Although user mode and kernel mode are in the same memory address space, user mode cannot access kernel mode memory. Memory pages are protected with flags, like R/W (Read/Write), U/S (User/Supervisor). A S-marked page cannot be accessed by user mode code. Protection between kernel and user mode is still in place.

Re: From Java code to Java heap (2012)

#49

Post by pjmlp »

pron wrote: post #42
fauigerzigerk wrote: post #40

Earlier quoted context omitted.

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

> 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 object layout.

Even the Scala guys are now researching into Scala Native.

Re: From Java code to Java heap (2012)

#50

Post by hyperpape »

dr_rust wrote: post #24
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.

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.

Yes, because many of them allocate a zero size array when you call their constructor and then lazily add to it. But that isn't really about object layout as I think of it, so much as what the fields of a particular object are.
Post reply on HN