×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Book Review: Java Performance

samzenpus posted more than 2 years ago | from the read-all-about-it dept.

Book Reviews 160

jkauzlar writes "The standard Oracle JVM has about sixty 'developer' (-XX) options which are directly related to performance monitoring or tuning. With names such as 'UseMPSS' or 'AllocatePrefetchStyle', it's clear that Joe Schmo Code Monkey was not meant to be touching them, at least until he/she learned how the forbidding inner recesses of the JVM work, particularly the garbage collectors and 'just-in-time' compiler. This dense, 600-page book will not only explain these developer options and the underlying JVM technology, but discusses performance, profiling, benchmarking and related tools in surprising breadth and detail. Not all developers will gain from this knowledge and a few will surrender to the book's side-effect of being an insomnia treatment, but for those responsible for maintaining production software, this will be essential reading and a useful long-term reference." Keep reading for the rest of jkauzlar's review.In my experience, performance tuning is not something that is given much consideration until a production program blows up and everyone is running around in circles with sirens blaring and red lights flashing. You shouldn't need a crisis however before worrying about slow responsiveness or long pauses while the JVM collects garbage at inconvenient times. If there's an opportunity to make something better, if only by five percent, you should take it, and the first step is to be aware of what those opportunities might be.

First off, here's a summary of the different themes covered:

The JVM technology: Chapter 3 in particular is dedicated to explaining, in gory detail, the internal design of the JVM, including the Just-In-Time Compiler and garbage collectors. Being requisite knowledge for anyone hoping to make any use of the rest of the book, especially the JVM tuning options, a reader would hope for this to be explained well, and it is.

JVM Tuning: Now that you know something about compilation and garbage collection, it's time to learn what control you actually have over these internals. As mentioned earlier, there are sixty developer options, as well as several standard options, at your disposal. The authors describe these throughout sections of the book, but summarize each in the first appendix.

Tools: The authors discuss tools useful for monitoring the JVM process at the OS level, tools for monitoring the internals of the JVM, profiling, and heap-dump analysis. When discussing OS tools, they're good about being vendor-neutral and cover Linux as well as Solaris and Windows. When discussing Java-specific tools, they tend to have bias toward Oracle products, opting, for example, to describe NetBean's profiler without mentioning Eclipse's. This is a minor complaint.

Benchmarking: But what good would knowledge of tuning and tools be without being able to set appropriate performance expectations. A good chunk of the text is devoted to lessons on the art of writing benchmarks for the JVM and for an assortment of application types.

Written by two engineers for Oracle's Java performance team (one former and one current), this book is as close to being the de facto document on the topic as you can get and there's not likely to be any detail related to JVM performance that these two men don't already know about.

Unlike most computer books, there's a lot of actual discussion in Java Performance, as opposed to just documentation of features. In other words, there are pages upon pages of imposing text, indicating that you actually need to sit down and read it instead of casually flipping to the parts you need at the moment. The subject matter is dry, and the authors thankfully don't try to disguise this with bad humor or speak down to the reader. In fact, it can be a difficult read at times, but intermediate to advanced developers will pick up on it quickly.

What are the book's shortcomings?

Lack of real-world case studies: Contrived examples are provided here and there, but I'm really, seriously curious to know what the authors, with probably two decades between them consulting on Java performance issues, have accomplished with the outlined techniques. Benchmarking and performance testing can be expensive processes and the main question I'm left with is whether it's actually worth it. The alternatives to performance tuning, which I'm more comfortable with, are rewriting the code or making environmental changes (usually hardware).

3rd Party tool recommendations: The authors have evidently made the decision not to try to wade through the copious choices we have for performance monitoring, profiling, etc, with few exceptions. That's understandable, because 1) they need to keep the number of pages within reasonable limits, and 2) there's a good chance they'll leave out a worthwhile product and have to apologize, or that better products will come along. From my point of view, however, these are still choices I have to make as a developer and it'd be nice to have the information with the text as I'm reading.

As you can see, the problems I have with the book are what is missing from it and not with what's already in there. It's really a fantastic resource and I can't say much more than that the material is extremely important and that if you're looking to improve your understanding of the material, this is the book to get.

You can purchase Java Performance from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

160 comments

60 options? (-1)

Anonymous Coward | more than 2 years ago | (#39079637)

They should be 0. Or maybe 1. This just proves that Java is a piece of shit in every regard.

Re:60 options? (2)

Pieroxy (222434) | more than 2 years ago | (#39080043)

They should be 0. Or maybe 1. This just proves that Java is a piece of shit in every regard.

20 words to say that? There should be 0. Or maybe one. This just proves that AC is a piece of shit in every regard.

Re:60 options? (-1)

Anonymous Coward | more than 2 years ago | (#39080199)

I'm backwarding to Java JDK 1.3.1 for hacking it that will provide my two essential statements:

  1. 1. label <label>:
  2. 2. goto <label>;

Then, i'll can build easily the textual computer translators Scheme->Java, CommonLisp->Java, Prolog->Java, PostScript->Java, Forth->Java, Smalltalk->Java, Javascript->Java, Snobol->Java, and so on.

After many years of dying JVM development of ex-company Sun, the performance doesn't affect me. This JVM is only a toy that sometimes works, another times it doesn't work.

JCPM: i didn't the KISS principle.

Re:60 options? (0)

Anonymous Coward | more than 2 years ago | (#39081401)

Cool story bro

Java Performance. There's an oxymoron (-1, Flamebait)

Anonymous Coward | more than 2 years ago | (#39079649)

By Charlie Hunt? What about his brother Mike?

Dead trees == outdated as soon as printed (4, Informative)

idontgno (624372) | more than 2 years ago | (#39079663)

It seems this kind of volatile deep non-documented black magic might change radically from JVM revision to revision. Although the Oracle "documentation" page [oracle.com] seems to contain a lot of "legacy" options, there still seems a risk that this book would be outdated as soon as the next JVM release.

Oh, well, the tech publishing industry seems to be doing pretty well, even if the rate of technology change means that a tech fact is OBE before it's committed to ink.

Re:Dead trees == outdated as soon as printed (4, Informative)

MightyMartian (840721) | more than 2 years ago | (#39079715)

Indeed. These sorts of options are so version dependent (not even going to alternative implementations) that I think the overwhelming majority of developers would want to stay far away from this sort of book.

Re:Dead trees == outdated as soon as printed (0, Troll)

MightyMartian (840721) | more than 2 years ago | (#39079925)

Why in the fuck was I modded troll? I guess the repugnant little asshats pushing this book must have some points. Fucking worthless pathetic immoral assfuckers.

Re:Dead trees == outdated as soon as printed (2, Insightful)

rezalas (1227518) | more than 2 years ago | (#39080021)

Why in the fuck was I modded troll?

Good question, but this follow up statement may be holding a clue:

I guess the repugnant little asshats pushing this book must have some points. Fucking worthless pathetic immoral assfuckers.

Yeah, that blurb didn't help ya.

Re:Dead trees == outdated as soon as printed (0)

Anonymous Coward | more than 2 years ago | (#39080155)

I'm guessing your winning personality had something to do with it. Try not sounding like a three year old with Tourette's if you'd like people to respect your opinion. In fact, judging by your post history I'm wondering why it is you're confused people judged you a troll in the first place, it's obviously not the first time.

Re:Dead trees == outdated as soon as printed (-1, Troll)

MightyMartian (840721) | more than 2 years ago | (#39080315)

That came after the moderation. And if you look, someone modded the parent I was replying to Troll as well. Mod my outburst as Troll but my original post was pertinent, on-topic, and certainly not trollish. Maybe it was wrong, in which case Overrated might apply, but Troll? Read the bloody post. Nothing trollish about it at all.

Re:Dead trees == outdated as soon as printed (0)

microbox (704317) | more than 2 years ago | (#39081339)

You have been the best entertainment all day. Let me guess -- the girls just /love/ you =0

Re:Dead trees == outdated as soon as printed (3, Interesting)

fusiongyro (55524) | more than 2 years ago | (#39080875)

They're not going to throw out the JVM and rewrite it from scratch between releases. If there are 60 options now, there may be 66 in the next release. That means 90% of the book is still useful and the other 10% is just missing.

On top of that, as the reviewer clearly states "Unlike most computer books, there's a lot of actual discussion in Java Performance, as opposed to just documentation of features.... there are pages upon pages of imposing text, indicating that you actually need to sit down and read it...". So this book is already the kind of book that isn't going to be overturned by one more JVM release. It may contain actual wisdom rather than a list of flags.

Re:Dead trees == outdated as soon as printed (2)

idontgno (624372) | more than 2 years ago | (#39079717)

And, in good Slashdot form, replying to myself (explain again why don't we have an "edit" button?), I read on the very Oracle web page I cited earlier:

Options that are specified with -XX are not stable and are not recommended for casual use. These options are subject to change without notice.

So, the "-XX" options are unstable and are subject to change without notice, which is why we have to commit them to a $25 to $35 pile of dead trees.

Re:Dead trees == outdated as soon as printed (4, Informative)

DiegoBravo (324012) | more than 2 years ago | (#39080003)

Apparently just the chapter 7 is about the XX:

  Chapter 1: Strategies, Approaches, and Methodologies, Chapter 2: Operating System Performance Monitoring, Chapter 3: JVM Overview, Chapter 4: JVM Performance Monitoring, Chapter 5: Java Application Profiling, Chapter 6: Java Application Profiling Tips and Tricks, Chapter 7: Tuning the JVM, Step by Step, Chapter 8: Benchmarking Java Applications, Chapter 9: Benchmarking Multitiered Applications, Chapter 10: Web Application Performance, Chapter 11: Web Services Performance, and Chapter 12: Java Persistence and Enterprise Java Beans Performance.

BTW, of course you should avoid the XX options, but when in need, it is better to have some authoritative reference than having to rely on the uninformative Oracle docs or random forums.

Book details correct? (0)

Anonymous Coward | more than 2 years ago | (#39079689)

I want to purchase, but I see a book with the same title, but different ISBN, and different number of pages on amazon. Can you double check these values?

Re:Book details correct? (1)

gweihir (88907) | more than 2 years ago | (#39079845)

May be an Amazon fraudster trying to ride on this. Better be sure before you buy.

lol java weenies (-1)

Anonymous Coward | more than 2 years ago | (#39079769)

it's clear that Joe Schmo Code Monkey was not meant to be touching them

Doesn't that then disqualify pretty much 99.9% of Java scripters (and yes you are scripters not programmers)?

Re:lol java weenies (2, Informative)

Anonymous Coward | more than 2 years ago | (#39079973)

Loser: Javascript != Java

Re:lol java weenies (0)

Anonymous Coward | more than 2 years ago | (#39079981)

You're confusing ECMAScript (JavaScript) with Java. You should know what you're talking about before you make a fool out of yourself again.

Re:lol java weenies (-1)

Anonymous Coward | more than 2 years ago | (#39080059)

No, I'm not. Flail harder, though, Java weenie. If you ever get fired I'm sure McDonalds will take you back as head fry cook.

Re:lol java weenies (1)

nobodylocalhost (1343981) | more than 2 years ago | (#39080591)

Hmmm, what are you talking about? Java is about as much of a scripting language as z80 assembly. When you run JVM, it essentially is an emulator, emulating imaginary hardware. Just like running a z80 processor emulator on your intel/amd/ppc/sparc cpu. Would you call z80 assembly a scripting language? When op talk about relations between JVM and Joe Schmo Code Monkey, what he really meant was "Programming in Java is very different from knowing your hardware and the hardware you are trying to emulate in order to figure out the most efficient way to complete tasks". Albeit Java was never designed to be efficient. The goal was to make a standard portable environment across many processors and operating systems. So performance tuning in one environment may very well be detrimental in another. As such mastery in performance tuning also varies from environment to environment. Someone who's awesome at tuning Java performance on solaris/sparc may totally suck at tuning Java performance on linux/intel. All in all, i think your assessment is oversimplifying and generally ignorant.

Re:lol java weenies (-1)

Anonymous Coward | more than 2 years ago | (#39080635)

Whatever you say, weenie boy. Java is a pathetic scripting language.

Re:lol java weenies (1)

Brian Feldman (350) | more than 2 years ago | (#39082675)

Actually, a modern Java Virtual Machine and JavaScript Virtual Machine are far more similar than they are different.

Currently reading (2, Informative)

Anonymous Coward | more than 2 years ago | (#39079795)

The development team at my company is currently reading this book. I'm three chapters in, and am having a hard time following it all. I often have to reread paragraphs, or entire pages, as soon as I finish them just to keep terms and names straight. Some applications which are discussed are five words long, like Microsoft Process Performance Analysis Console, or something head-spinning like that. That's the actual name of the application, so there is no other way to refer to it, so it's just the nature of the material. It's a good reference, and I'd highly recommend reading it if you work with Java full-time. The information for debugging and fixing performance issues is invaluable. Just be sure to take your Ritalin or Adderall before hand.

Futile (-1, Flamebait)

gweihir (88907) | more than 2 years ago | (#39079833)

Optimizing Java is sort-of like optimizing a low-powered family car: It does not make a lot of sense. If you really need performance, go to C (or if you cannot avoid it, C++). Of course , then you have to hire people that actually know how to program close to the metal.These may be a tad more expensive than generic Java programmers, but the results will make it worth your while.

Re:Futile (-1, Troll)

Anonymous Coward | more than 2 years ago | (#39079855)

Programming in C++ doesn't require baremetal knowledge. You just need to have a functioning brain and not be a mouthbreather. Basically you have to be more qualified than the average Java weenie who would struggle even in a fry cook position.

Re:Futile (4, Insightful)

Brian Feldman (350) | more than 2 years ago | (#39080907)

Oh, please, neither Java nor C++ is superior to the other. They both have strengths at certain kinds of programming but altogether support extremely similar semantics in most areas. There are very difficult-to-use portions of both Java and C++. You should get yourself some more experience.

Re:Futile (0)

helixcode123 (514493) | more than 2 years ago | (#39079877)

That's what JNI is for. Write your performance-critical code in C.

Re:Futile (1)

Anonymous Coward | more than 2 years ago | (#39079913)

No, it's more like raising the efficiency of your diesel 18-wheeler by a few mpg and pocketing the savings.

Re:Futile (0)

Anonymous Coward | more than 2 years ago | (#39079941)

Nicely played. Let's see if you get any bites!

Re:Futile (1)

Anonymous Coward | more than 2 years ago | (#39079975)

I'd just like to point out that often even economy cars are worth upgrading for performance because car-makers often hamper their own designs for various reasons (e.g., severely under-dampening the suspension).

Also, do any JREs actually support NIO direct buffers*? I tried it on OS X and Amazon's Karmic 64 nodes about a year and a half ago and it didn't work, thus doubling my memory and severely hampering a project (since I unfortunately had to program sockets for the first time in over a decade and was advised to go with Java over C). Unless distributions actually support direct buffers, using C in Java is much worse than it needs to be.
*I think that's the right term for sharing memory between C and Java.

Re:Futile (1)

viperidaenz (2515578) | more than 2 years ago | (#39081413)

direct buffers work in windows. you just need enough contiguous memory space available to allocate the buffer to.

Re:Futile (2, Interesting)

Anonymous Coward | more than 2 years ago | (#39079997)

I'm working on the inverse right now. Porting C code to Java and improving it. It does take longer to run, but it's also doing a lot more. However, setting up a worker thread pool in java is much easier than doing threading in C. With the -server flag and some tuning for max ram usage, it can do a reasonable amount of work. Of course the RAM needed for the program is much larger than it's C counterpart.

Re:Futile (2)

gweihir (88907) | more than 2 years ago | (#39081959)

If you do not have a performance issue, that is fine. Personally, Prototype in Python and port time-critical parts to C. (Object-oriented C, as far as it makes sense.)

What I do not like about Java is that it is neither a really modern language like Python, nor a really fast and memory-efficient language like C. It is sort of a jack-of-all trades and good at none. It is also a master of syntactic clutter and complex, long code. Still, if you really know what you are doing, you can write good Java code.

As to the worker-thread pool, if you stay within the limits of the VM, it is admittedly easy to do something like that in Java. But as soon as you go beyond the not very impressive capabilities of the typical Java VM, you are screwed. But my guess would be you know that are are staying within these limits. So, yes, if you know what you are doing, even porting C to Java can make sense.

Re:Futile (5, Insightful)

Ichoran (106539) | more than 2 years ago | (#39080061)

There is a _big_ difference between clumsily optimized (or unoptimized) Java and carefully-optimized Java--more, in my experience, than the difference between clumsily optimized Java and clumsily optimized C or C++. So if you are already using Java for some reason (robustness to faults, ease of parallelism of certain kinds (w.r.t. C), library that does exactly what you need, etc.), you should figure out how to optimize it before bailing out and using a different language.

Only if you absolutely must get as much out of your hardware as physically possible should you start using C/C++, and at that point, don't expect to be using ANSI C; you should be issuing SSE4 instructions and such (basically writing targeted assembly, even if you are doing so in a way that looks like C functions) that have been cleverly crafted to do exactly what you need.

(And don't forget that while you are taking extra time to write all this low-level high-performance code, your computers _could_ have been running using the slower code, making progress towards a solution, or serving customers albeit with delays, etc..)

Re:Futile (4, Insightful)

Mr Thinly Sliced (73041) | more than 2 years ago | (#39080329)

Fair points but I'd say there's a few places that Java just doesn't cut it - strict scheduling and / or real time needs. O, and GUI stuff, too.

So basically, no GUI, no audio, no video. Which only more or less leaves what it currently is king of the hill for - server side business processing.

I've tried real time and Java, and the jitter that garbage collection introduces (yes, even with parallel garbage collection and all that stuff) makes it hugely unpredictable.

Strangely enough, the company formerly known as SUN knew this, and tried to create a "real time" [sun.com] flavour of Java with such extensions - but it takes so much effort to port your code (and the JVM is slightly less than brilliant) that you're far better off going to C/C++.

Re:Futile (1)

Ichoran (106539) | more than 2 years ago | (#39080417)

Agreed--you need to use libraries written in C/C++ for audio/video. But you can certainly call them from Java, as long as they handle the streaming side of things on their own. Whether or not it's suitable for GUI work depends on what you want your GUI to look like; if platform integration is your top priority (default widget sets, color schemes, etc.) then no, it doesn't work so well. Otherwise, it's not fantastic but it's servicable (again assuming blistering performance isn't necessary).

Re:Futile (1)

HarrySquatter (1698416) | more than 2 years ago | (#39080645)

No for audio/video you need libraries written using SIMD assembly. Anything else is going to be way too slow.

Re:Futile (1)

gweihir (88907) | more than 2 years ago | (#39081981)

That is nonsense. As long as you get good scheduling responsiveness, C is entirely fine. The problem with Java is not even the language itself (slow as it may be), but the garbage collection.

Re:Futile (1)

smellotron (1039250) | more than 2 years ago | (#39082709)

As long as you get good scheduling responsiveness, C is entirely fine.

Yes; GCC and ICC are quite good at optimizing SSE intrinsics, to the point that hand-coded asm can be largely avoided. I have heard otherwise for Visual Studio; fortunately, Intel's compiler works on Windows as well. As to the rest of the code, well... just keep an eye on the assembler output from every. single. build.

Re:Futile (1)

viperidaenz (2515578) | more than 2 years ago | (#39081453)

So basically, no GUI, no audio, no video.

That's why Vuze doesn't have an integrated video player or a native, cross platform GUI.

Re:Futile (1)

Mr Thinly Sliced (73041) | more than 2 years ago | (#39081549)

That's why Vuze doesn't have an integrated video player or a native, cross platform GUI.

Given Vuze does have (kinda) those things, I assume you're advocating that Java does?

I'd hardly say using third party toolkits and/or native blobs written in another language (for both of those you mention) adds weight to the strengths of Java....

In fact, it confirms what I said - you don't do those things in Java.

Re:Futile (2)

viperidaenz (2515578) | more than 2 years ago | (#39082493)

SWT is quite a popular Java library written by one of the JVM vendors. Java is the only platform I know that has libaries to write a GUI that runs on Windows, Mac, Linux, Firefox, Chrome, Opera and Internet Explorer

Re:Futile (3, Insightful)

smellotron (1039250) | more than 2 years ago | (#39082681)

...the jitter that garbage collection introduces makes it hugely unpredictable... you're far better off going to C/C++.

Unfortunately, when you really get down to it you will have similar problems in C or C++. You cannot allocate memory from the system heap (malloc or operator new) in the critical path of real-time code. That means everything is preallocated. That means you could have been using Java anyways, with GC disabled. There may be other reasons to use C or C++ for these systems, but the nondeterminism of dynamic memory allocation really applies across the board. It just hits Java users earlier.

Re:Futile (2)

bws111 (1216812) | more than 2 years ago | (#39081693)

The switches and controls described are run-time options, not code optimizations. They are more like the 'economy or performance' transmission setting. Sometimes you want to get the best MPG and don't particularly care how fast you accelerate. Other times you want quick acceleration, and are willing to let mileage suffer. Having a control means you don't have to re-build your car every time you want a change.

These options are the same kinds of things. If you only have one application running on a box you may as well let the JVM grab as much of the physical memory as it can, so it does as little garbage collecting as possible. If you add more applications you may want to dial back the memory usage and take a performance hit for that application so other more important apps run better.

Can you do the same things with C or C++? Of course, as long as each and every application provides its own controls, coded into the applications, for doing that.

Re:Futile (1)

gweihir (88907) | more than 2 years ago | (#39081993)

I must have misread the article. 600 pages to describe VM parameters? How insane is that! Java is turning into a more and more complex mess all the time.

Re:Futile (4, Informative)

bws111 (1216812) | more than 2 years ago | (#39082095)

More like you didn't read it at all. Right in the summary it says: This dense, 600-page book will not only explain these developer options and the underlying JVM technology, but discusses performance, profiling, benchmarking and related tools in surprising breadth and detail.

Re:Futile (0)

Anonymous Coward | more than 2 years ago | (#39082249)

The C Programming Language is just 228 pages. It explains the entire language.

This book is 600 pages. It explains the 60 possible command line options for the JVM.

Java: Enterprisey.

Re:Futile (1)

bws111 (1216812) | more than 2 years ago | (#39082597)

Are you really that dense? It describes the command line options (which would have to be written into your own application if you wanted to have that level of tuning in C). It describes the technology of the JVM (so add some books describing processors and OS internals to your list). It describes performance, profiling, benchmarking, and the tools used to do those things (add a few dozen more books to your list).

Now obviously C is much easier to do those things with. That is why the first tool for analyzing C memory usage (ThreadSpotter) takes a 149 page book to describe it. So your C library is already up to 377 pages, and you haven't even touched on the technology issues. And of course any documentation on how to tune your application must be written by you.

Re:Futile (0)

Anonymous Coward | more than 2 years ago | (#39081797)

Microsoft Works
Military Intelligence
Java Performance

Blablabla (-1)

Anonymous Coward | more than 2 years ago | (#39079911)

What performance?

How much difference do these options really make? (2)

naasking (94116) | more than 2 years ago | (#39080095)

I can see the use for options to specify heap sizes, and to tweak latency vs. throughput of the GC. These are critical for memory-constrained and timing-constrained applications, respectively. I presume the other options are performance related, but how effective are they really?

Re:How much difference do these options really mak (4, Funny)

DalDei (1032670) | more than 2 years ago | (#39080185)

-XX11 is useful as its +1 faster than -XX10, should be the default really.

Re:How much difference do these options really mak (1)

naasking (94116) | more than 2 years ago | (#39080255)

And does the numeric value of that option dictate the degree of JIT-time optimization performed?

Re:How much difference do these options really mak (1)

robot_love (1089921) | more than 2 years ago | (#39082357)

-XX11 is useful as its +1 faster than -XX10, should be the default really.

I hear they're contemplating a "-XX12" option that threatens to rip asunder the very fabric of time and space.

Re:How much difference do these options really mak (0)

Anonymous Coward | more than 2 years ago | (#39080241)

-XX:+UseConcMarkSweepGC helps a ton if you need low latency, and have at least 4 cores.

Re:How much difference do these options really mak (1)

Anonymous Coward | more than 2 years ago | (#39080633)

Why do you need to specify heap size at all?
Every native program can allocate just as much heap as it needs from Virtual Memory, and no more.

Re:How much difference do these options really mak (2)

medv4380 (1604309) | more than 2 years ago | (#39080797)

You have a point, and the answer isn't any good ether. You specify the Heap size so that the Garbage Collector can be lazy and not clean up memory until the specified heap is at a certain level. I think it's just a Java thing. C# and .net grow as needed up to the systems limit. GoLang even though native is Garbage Collected (sorta) and I've yet to find some arbitrary default if one exists. Java only wants to use 1/4th or less of the available system memory, and I can only think of reasons linked to Garbage Collection.

Re:How much difference do these options really mak (3, Interesting)

SplashMyBandit (1543257) | more than 2 years ago | (#39081281)

Bugger. I had modded a bunch of posts on this thread and now have to chuck them away just to counter your ignorance (lest your incorrect assumption spread to others). It's cool you are taking a stab at why Java might limit memory, but unfortunately that guess is not correct - so I hope to set yourself (and any other readers) straight on why Java has this feature (if you don't understand the feature you'll see it as a limitation, when in fact it is very important for security).

The limit Java imposes on memory is to ensure that critical resources (memory) is preserved for the system - and gives the Java user a way to limit what any application can do. This is a very important protection if you followed Java's internet model where Applets (or these days, WebStart applications) and allow remote applications to run. System administrators can also partition what any application can do, in case one is rogue (they can't trust those damn application developers, like me) and uses up all the system memory shared between many applications when running on Big Iron. I don't know whether any remote running .NET applications have this protection and would be interested to hear if they do - if they don't then that means any .NET application could in theory bring your server (and all the other important services you have running on it) to a crawl (as it swaps memory) or possibly even crash through memory exhaustion.

Re:How much difference do these options really mak (1)

Bill, Shooter of Bul (629286) | more than 2 years ago | (#39081989)

Double Bugger. I was going to mod you up, but you're sort of missing a piece of the puzzle. Java is supposed to be Write once run anywhere. So, yes a decent operating system should be able to enforce memory limits of applications so they don't bring your server to a crawl, but that's not built into Java, so they had to do it by default with the stupid limitation on all programs.

Re:How much difference do these options really mak (1)

SplashMyBandit (1543257) | more than 2 years ago | (#39082633)

Please elaborate how this affects the "Write once run anywhere". I'm afraid I don't quite get what you mean. Thanks.

Re:How much difference do these options really mak (2)

bws111 (1216812) | more than 2 years ago | (#39082745)

The book is discussing run-time tuning, so 'write once run anywhere' does not enter into it.

It seems that a lot of people on here don't 'get' run-time tuning, or they don't think it is important. In the environment that these parameters would normally be used (enterprise software), tuning is critical. All enterprise middleware and most applications have tons of tuning. In an enterprise environment you do want the ability to trade off memory usage for processor usage, for instance. You want to control how much memory is being used. You want to control how many cores your application can use. And those things change depending on lots of variables. For example, at different points during the year different applications may have higher or lower priorities. Workload can be added to or removed from an image, requiring rebalancing of resources. You may find that scaling an application up or down requires different handing of garbage collection.

Now, all these things can be done (and must be done in an enterprise) regardless of language. If you don't have a tunable run-time then the other option is that every application builds in it's own tuning parameters.

java se or java ee? (1)

edxwelch (600979) | more than 2 years ago | (#39080149)

I wonder what type of projects would need to tweek the jvm. I am assuming it's huge java web based enterprise applications.

Too many options (4, Insightful)

medv4380 (1604309) | more than 2 years ago | (#39080205)

The JVM really needs to get smarter. 60 different controls and switches is just too much. How hard can it be for the JVM to look at the available number of cores and just turn on the Parallel Garbage Collector. Do I really have to manually turn it on so that Minecraft will use it? Why can't the JVM allocate more memory on its own? Does it really need permission to use more than 1 Gig of memory? It just sits there waiting for the day some user decides to import every single possible datapoint into it, crashes, having used 1 Gig of 8, with a "Out of Memory" error. It's not like Developers know what the Xmx and Xms setting need to be. They just set them arbitrarily high in hopes that some user doesn't try to find out what the maximum datafile it can take is. That just slows it down and makes it so when the GC finally does fire off it has 10x the amount of trash it should have if the value was set lower. Those options are only useful on internal applications that never get into the hands of everyday users. It's probably a great book for server side development, but it is highlighting a major failing of the JVM.

Re:Too many options (2, Interesting)

Anonymous Coward | more than 2 years ago | (#39080697)

Really, just set -Xincgc -Xmx# and walk away.

It does periodic GC with that, not waiting for the crash.

Re:Too many options (4, Interesting)

medv4380 (1604309) | more than 2 years ago | (#39080971)

You didn't prove anything except point out yet another option to be set. If that was the best way to set the JVM why isn't that the default. Why is it left up to the user to specify it. Why do users have to figure out how to tweak it so that Minecraft work "optimally" on multicore machines? When you have to figure out this

java -Xmx1024M -Xms1024M -XX:+UseFastAccessorMethods -XX:+AggressiveOpts -XX:+DisableExplicitGC -XX:+UseAdaptiveGCBoundary -XX:MaxGCPauseMillis=500 -XX:SurvivorRatio=16 -XX:+UseParallelGC -XX:UseSSE=3 -XX:ParallelGCThreads=4 -jar /media/storage/minecraft.jar

-Xincgc might sound good but then again

-Xincgc Enable the incremental garbage collector. The incremental garbage collector, which is off by default, will eliminate occasional garbage-collection pauses during program execution. However, it can lead to a roughly 10% decrease in overall GC performance.

Re:Too many options (1)

bws111 (1216812) | more than 2 years ago | (#39081541)

The major use of Java is server side enterprise stuff, and all those controls are critical there. It is certainly not a major failing of the JVM, it is an important feature. The alternative to the JVM having all those controls is for each and every application to have its own controls.

Re:Too many options (2)

idontusenumbers (1367883) | more than 2 years ago | (#39081823)

Some of these directives may be VM specific and might change the way synchronization or allocation works in such a way that it's inconsistent with the "default" and break applications that weren't tested with these options. Additionally, Java has a tendency to pre-allocate memory when it's not needed in preparation for future allocation. Operating systems will likely show this as "memory in use" even though Java will give up this memory when it detects the OS is running low. Users that aren't aware of this may claim "Java is a memory hog" when really it's just being efficient. Allowing developers to put a cap on this maximum size can help alleviate users complaints as the developer should be able to determine a reasonable maximum amount of memory.

tuning performance vs production blows up (4, Informative)

roman_mir (125474) | more than 2 years ago | (#39080227)

In my experience, performance tuning is not something that is given much consideration until a production program blows up and everyone is running around in circles with sirens blaring and red lights flashing.

- if production blows up it signals that the underlying problem is not likely to be fixed with 'performance tuning'.

There is performance deficiency and then there is "production blows up" and those are different things and must be addressed by different sets of practices at different times.

Production blowing up means the design is flawed, it means misunderstanding of how the application was going to be used.

Slow response time on the other hand is about tuning, but it's very unlikely that environment tuning can help really to fix this.

Back in 2001 I was working for then Optus that was bought out by Symcor and the main project they brought me to (contract) was for this Worldinsure [insurance-canada.ca] insurance provider, and the project was to do some weird stuff, business wise speaking, allow clients to compare quotes from different insurance providers. Business model was changing all the time, because insurance providers do not want their products to be compared against one another on line (big surprise).

The contract was expensive (5million) and WI wouldn't pay the last bit (a million I think) until the application would start responding at a 200 requests per second, and it was doing 20 or so :)

If anybody thinks that just some VM tuning can fix a problem where application is 10 times slower than expected, well, you haven't done it for long enough to talk about it then.

It took a month of work (apparently I wrote a comment on it before) [slashdot.org] that included getting rid of middleware persistence layer, switching to jsp from xslt, reducing session size by a factor of 100, desynchronising some data generators, whatever. Finally it would do 300 requests per second.

But the point is that when things are crashing or when performance is really a huge issue, you won't be optimising the VM.

VM optimisation is not generally done because I think the application has to do something that is not generic.

Imagine an application that only does one thing - say it only reads data from a file and then runs some transformation on it, maybe it's polygon rendering. Well then you know that your app. is doing only ONE THING, then you can probably use VM optimisation, because you can check that the one thing your app does will become faster or more responsive, whatever.

But if your app includes tons of functionality and tons of libraries that you don't have control over and it runs in some weird container on top of JVM, then what do you think you are going to achieve with this?

You likely will optimise something very specific and then you'll introduce a strange imbalance in the system that will hit you later and you won't see it coming at all.

If your app does one thing, maybe you have a distributed cluster with separate instances being responsible for one type of processing, then you probably can use specific optimisation parameters.

Re:tuning performance vs production blows up (0)

Anonymous Coward | more than 2 years ago | (#39080291)

mod parent up

Performance battles of GCed languages. (0)

Anonymous Coward | more than 2 years ago | (#39080337)

My three favourites languages for programming that include an integrated garbage collector and are on top level of CPU performance are:

  1. 1. ex-Sun's 32-bit JDK 1.3.1 hacked by myself for providing two statements label/goto in this ancient language old Java.
  2. 2. Glasgow Haskell Compiler (GHC 7.5 devel) as in http://www.haskell.org/ghc/dist/current/dist/ghc-7.5.20120214-x86_64-unknown-linux.tar.bz2 [haskell.org]
  3. 3. The coming OCaml-3.13.0 that will provide its new feature GADT that did exist in GHC.

Successful stories: Apache's Hadoop over JVM, Plasma compiled by OCaml, Agda type assistant, etc.

JCPM: and what about slower programming languages? I won't use them much unless stupid code around there (e.g. bash for commands, html for layout, etc).

Here is an idea (0)

Anonymous Coward | more than 2 years ago | (#39080299)

You could also just use a faster programming language.

Re:Here is an idea (2)

roman_mir (125474) | more than 2 years ago | (#39080391)

I have news for you that may just be too hard to swallow - it is absolutely possible, and it happens all the time, that garbage is written in all sorts of programming languages.

The actual problem is often found between the chair and the keyboard (or more generically, somewhere in wetware of the people involved, developers, designers, management, etc.)

Feed me (-1)

Anonymous Coward | more than 2 years ago | (#39080521)

Java performance? If I don't see a hilarious comment about the absurdity of that phrase, I will be disappointed. I understand this subject deserves respect, but I also need to see the obvious and easy java bashing to continue. Apologies.

90% of comments not surprising (-1)

Anonymous Coward | more than 2 years ago | (#39080667)

As usual, most of the population of slashdot just falls over itself with derp-ful responses trying to be oh-so-witty-and-clever with their comments about java performance.

If this is news for nerds, I'd like to find someplace with actual nerds worthy of the name.

I don't use anything but heap settings (4, Informative)

msobkow (48369) | more than 2 years ago | (#39080711)

I've worked with Java since 1.0. The only optimization options I've ever used were the heap and stack size adjustments.

Setting your memory heap too high actually degrades performance, oddly enough. I've got 4GB on this box and over 2.5G is normally used by disk cache, but if I allocate more than about 768MB to the heap, the performance suffers.

Maybe some of these options have real effects on certain production code characteristics, but I've found the best performance tuning options are:

  • Whenever and wherever possible, use intrinsic types, especially extracting a char from a string for evaluation rather than using the object accessors for a String. For whatever perverse reason, the Oracle Java compiler will keep re-fetching the value by re-executing the getChar() rather than realizing it's a constant once the value has first been extracted, because the String isn't changing. Net performance boost for my code: over 30% improvement for a days coding on a multi-year project.
  • Instead of allocating and destroying objects, consider hanging on to used objects and using your own allocator. This won't help for implicit object construction, but reusing modifiable objects helps performance dramatically. I saw about a 10% performance improvement when I experimented with this. Raw object allocation is EXPENSIVE.
  • Wherever possible, tighten your loops into a single statement of execution. For unknown reasons, the JVM seems to perform better calling a small function fragment than it does executing inline code in a for/while loop block. This makes no sense based on what I know of C++ tuning, but there you have it: Java likes functions better than inline code when executing loops. Maybe there is some optimization that kicks in for a function that doesn't happen for a code block.
  • If possible, construct a huge single String assignment using conditional expressions (i.e. ( bool-expr ) ? ret-if-true : ret-if-false ) instead of appending to a string buffer with a sequence of if-then-elses. The code is harder to read, but for anything of moderate complexity you can achieve up to a 30% performance improvement by doing this.

So there you have it -- my favourite REAL WORLD, TESTED, and PROVEN TO WORK performance tweaks.

Re:I don't use anything but heap settings (1)

Anonymous Coward | more than 2 years ago | (#39081119)

unfortunately, some of these recommendations may be left over from java 1.0. i'm pretty sure object pooling became a bad idea right around the time that the generational gc became standard. with the generational gc, allocating and discarding short lived objects is dirt cheap. probably cheaper than maintaining your pool. not to mention that object pools have the characteristic of maintaining objects in old gen pools with references to objects in new gen pools, which is exactly what you _don't_ want with a generational gc.

Re:I don't use anything but heap settings (1)

Brian Feldman (350) | more than 2 years ago | (#39082777)

In the few instances I've seen a co-worker using object pools, removing them has been a benefit in every single way. Even if the objects do cost a little to construct, so does synchronously maintaining a giant linked list of objects.

Re:I don't use anything but heap settings (1)

SplashMyBandit (1543257) | more than 2 years ago | (#39081477)

Actually, re-using objects is an excellent strategy if you are using JavaBeans (where you have symmetric getters and setters). Unfortunately, so many programmers hide setters away from you, supposedly to protect you from yourself, but it makes it impossible to re-use objects even where it would otherwise not only be perfectly possible and valid but also very efficient as well. In short, use JavaBeans when you need complex (non-intrinsic) value-objects and make the setters symmetric with the getters, *always*. You don't generally need to work pools of objects if you can re-use a JavaBean directly. Immutable objects have their uses, but they are very expensive in many performance-critical situations. If an object doesn't have to be immutable, don't make it so (keep it a Plain Old Java Object [POJO] where you can).

Although if you do need pooling (and you do from time to time) then Apache Commons Pool has done all the work for you. Real-life example, I worked on an Internet-scale project where the cost of obtaining a java.util.Calendar was too expensive (since it internally gets a timezone) and affected a critical part of very heavily used code. Pooling instances was very helpful in keeping high performance.

As always with performance you ought to be profiling your code before optimizing. Fortunately the Java SDKs come with JVisualVM which is absolutely fantastic - you don't need to compile a special profiling version of your program (like C or C++) you can simply attach to *any* running Java process and see what it is up to. You can even do this to remote processes (although you get slightly less information than if you hook up to a local process). This is an unbelievably good feature that allows you to optimize your Java sensibly - which should result in code at least as fast as C if you know what you are doing.

Once you have done your profiling with JVisualVM you can figure out what you need to do next:
Am I doing a lot of string concatenation (eg. text or XML processing)? then changing one or two Strings to StringBuffers can often give you a factor of 10 speedup in critical code (I've done this myself)
If you are creating a lot of objects then having a fully mutable JavaBean can help (I've done this with a Matrix class - which saved re-initialising the identity matrix a lot).
If you are CPU bound then how about splitting your working into multiple threads? Much easier than doing multithreading in C or C++
Still don't have enough CPU power? cool, you're in Java so move your application from a little Windows box onto a Linux/Unix huge blade server.
are you multi-threaded but lock contention for shared resources holding you back? then get rid of that fancy shared singleton and use non-shared POJO objects in each thread to hold what would otherwise be shared state.
Running out of memory and is the GC thrashing? simple, just give your application more memory with the -Xmx JVM parameter.
Doing a lot of iteration over lists or arrays to find things? then create a java.util.Map to cache lookup data.
These are all simple fixes that can make Java very fast. JVisualVM will help you make the decision about where to start.

Of course, the classic paper discussing how fast the JVM had got even 4 years ago from the French supercomputing research arm of INRIA:
https://blogs.oracle.com/jag/entry/current_state_of_java_for [oracle.com]
If anyone still thinks the JVM is slow then they are out-of-date. As long as your developers are competent you can make Java applications very fast.

Re:I don't use anything but heap settings (1)

dr2chase (653338) | more than 2 years ago | (#39082263)

Problem with object pools (if you are multi-threaded) is that they you need to synchronize access to them, and THAT adds overheads and potential bottlenecks. You can make your pools thread-local, but then you've got to worry about them getting too large (how many threads do you have, also?). Unless you're doing some really expensive object preparation, if you've got a generational collector, that's usually a good bet -- simpler, fast enough, not a source of confusion six months down the road.

Re:I don't use anything but heap settings (1)

SplashMyBandit (1543257) | more than 2 years ago | (#39082665)

All good points. You don't even need do use a thread local, just have an independent pool per thread (assuming your threads are long lived and do a lot of work). Simple and is nearly as efficient as having a global pool, but without the locking overhead.

Re:I don't use anything but heap settings (1)

msobkow (48369) | more than 2 years ago | (#39083079)

I haven't had to do this with Java yet, but I have implemented thread-specific pools with multi-threaded C++ application code, where each thread had it's own pool. It was a critical performance tweak for one system I worked on 12-15 years ago, as we were pushing the hardware so hard that within a year the IO bus wouldn't be able to move the expected data even if it did nothing but shuffle MY module's data 24x7. (Yes, we EXPECTED to need new hardware, but we needed a solution NOW.)

Fortunately, Java seems to do some pooling of it's own for Strings and box types -- they perform FAR better than general objects, so they have to be doing something special for their allocation and destruction. In particular, I've found that well written Java string manipulation code actually outperforms my C++ code -- even though the Java code deals with UTF16 data instead of 8-bit ANSI/ASCII data. Or maybe byte manipulation on modern processors just isn't as efficient as it used to be.

Re:I don't use anything but heap settings (1)

Brian Feldman (350) | more than 2 years ago | (#39082761)

If you're building strings, use a sensible API like java.lang.StringBuilder (or if you're feeling unnecessarily anachronistic, java.lang.StringBuffer).

StringBuilder s = new StringBuilder("whatever");
s.append(somestuff);
s.append("someotherstuff");
return s.toString(); //note: all uses of APIs may be entirely inaccurate

If you want performance (2)

freeshoes (826204) | more than 2 years ago | (#39080745)

The more you abstract what's underneath the less performance you can achieve. Assembly vs C, C vs Java/C#/Python, Running code on a host vs a guest virtual machine, I think you get the point.

Java PERFORMANCE? (0, Troll)

atari2600a (1892574) | more than 2 years ago | (#39080769)

Sounds like an oxymoron to me...

Java is an oxymoronic toxic toy. (0)

Anonymous Coward | more than 2 years ago | (#39081113)

The Java's performance is worse due to many factors:

  1. 1. It's using <genericity> instead of <templating>.
  2. 2. Its <genericity> is limited to only non-primitive objects (e.g., you can't instantiate primitive types as boolean, int, long, float, double, etc).
  3. 3. It doesn't use the feature GADT as used in Glasgow Haskell Compiler and in the coming OCaml 3.13.0 that uses a most powerful type inference system known until the actuality.
  4. 4. Every objects are references to objects, not as expanded/aggregate types as in Eiffel.
  5. 5. It always did lack the most powerful CPU-performance Partial Evaluation as used in Psyco, PyPy, etc.
  6. 6. And didn't provide Ahead-Of-Time (AOT) for faster boot or reboot of the application.
  7. 7. It didn't provide my two essential statements label <label>: and goto <label>;.
  8. 8. And it's not multi-architecture yet (their supports to ARMv7, ARMv8, MIPS, Alpha, etc. are not available yet to the public).

JCPM: Java is still a toy, a baby of >10 years of unsustainable growning, and it's not adult yet.

Re:Java is an oxymoronic toxic toy. (1)

SplashMyBandit (1543257) | more than 2 years ago | (#39081645)

Interesting you know about odd, unpopular languages like Haskell but don't even know about GCJ, which would address your issue (6). The Oracle JVM is not the only JVM in existence. Plus, apart from start-up time (inconsequential on servers) the JIT generally produces faster code than AOT since superior optimisation information is available to a JIT instead of a AOT compiler. Even on the desktop these days were the JVM is pre-loaded by the OS the start-up time is not that long, and becomes increasingly insignificant as you move away from small programs to large programs (hell, MS Word takes forever to load on a clean reboot and that it written in C++).

As for (2). You don't need to have a generic instance of a primitive type. The JVM is smart enough to 'autobox' this for you (a nice feature Java stole from C#) with the resulting effect that you essentially get the generic class using primitive type and the resulting performance gain. Nice to have such things happen under the hood.

Strange you also would like to use goto. Even in 1968 Dijkstra considered this harmful in a famous paper - so generally anyone wanting to use this is considered slightly deranged, there are alternatives that are much more maintanable. So railing against Java for a construct that the consensus considers bad form could also be seen as bad form (or an unawareness of just how bad designs that need goto are).

Also, Java does provide labeled statements, and goto is reserved but not used. You can use the label to continue in a loop with a similar effect to goto - although as a said before, this is not encouraged by the consensus since usually the use of such a construct is considered 'harmful' to good development practices.

It's kinda amusing that you cherry pick the best features from a slew of languages and indicate that Java can't hold it's own against half-a-dozen languages at once, yet each of those languages blow when compared to Java one-on-one. That's pretty typical for the kind of academic language snobbery you get around here. When you start building *huge* systems you realise that the 'toy' languages you mention aren't really that good for developing in the large - plus they are good for specific problems and aren't really that well suited as a general purpose solutions that you are going to invest significant financial and developmental resources into (that is, build a business with many collaborating people that simply can't chose a new language du jour for their clients). The strengths of those alternative languages (and they have some for sure) become their weaknesses when solving the problems of scale and development continuity in the real world (that is, some of the nifty languages features actual hinder *getting real things done* - which is what really matters).

Re:Java is an oxymoronic toxic toy. (0)

Anonymous Coward | more than 2 years ago | (#39081861)

Briefly, the Oracle JVM is still almost frozen since that it was founded and although newer technologies were discovered but not added to this 'frozen' sw-engine, as by example, GADT type inference system, Partial Specialization, Supercompilation, etc.

JCPM: the company maintaining 'frozen' this thing for a dozen of years (instead of expanding the potential of this thing) is equal to DYING its involved MASSIVE communities into a kind of 'frozen' stucken-fake technology.

Re:Java is an oxymoronic toxic toy. (0)

Lawrence_Bird (67278) | more than 2 years ago | (#39082033)

Strange you also would like to use goto. Even in 1968 Dijkstra considered this harmful in a famous paper - so generally anyone wanting to use this is considered slightly deranged, there are alternatives that are much more maintanable. So railing against Java for a construct that the consensus considers bad form could also be seen as bad form (or an unawareness of just how bad designs that need goto are).

Clearly a member of the NannyState of programming. Will offer you a healthy alternative to that nasty goto/label that your mommy packed you for work today.

Re:Java is an oxymoronic toxic toy. (1)

SplashMyBandit (1543257) | more than 2 years ago | (#39082647)

Bah. The kind of reply I get when you've never had to review the work of a dozen lesser programmers to see what simple thing they didn't get right. More complexity is not better - it's a shame if you haven't grokked that.

Re:Java PERFORMANCE? (0)

Anonymous Coward | more than 2 years ago | (#39081171)

Sounds like an oxymoron to me...

Sounds like a moron to me...

600 pages? (0)

Anonymous Coward | more than 2 years ago | (#39081655)

The standard Oracle JVM has about sixty 'developer' (-XX) options which are directly related to performance monitoring or tuning... This dense, 600-page book

600 pages to explain 60 compiler options? That's why I really hate Java.

Why fiddle, just re-implement the damn thing (3, Informative)

saboosh (1863538) | more than 2 years ago | (#39082807)

An issue recently came up on my Engineering team where a pig mapreduce job that stores in hbase slowed over the course of completing tasks until all the tasks failed due to timeouts. What appeared to be happening was a gc failure and pause due to tenure region exaustion and the built in cluster function to kill off the garbage collecting regionserver. The link below describes the issue and possible workarounds by implementing a custom memory allocation strategy. It's also a must read for anyone who isn't a java garbage collection expert. http://www.cloudera.com/blog/2011/02/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-1/ [cloudera.com]
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...