Java Technology Home Page
A-Z Index

Java Developer Connection(SM)
Chat

Downloads, APIs, Documentation
Java Developer Connection
Tutorials, Tech Articles, Training
Online Support
Community Discussion
News & Events from Everywhere
Products from Everywhere
How Java Technology is Used Worldwide
Print Button
 
JavaLive Transcripts Index

JavaTM Platform Performance
August 29, 2000



Guest Speakers are Steve Wilson and Jeff Kesselman

This is a moderated forum

EdO: Welcome to Java Live! Our topic today is JavaTM performance. Our guests are Steve Wilson and Jeff Kesselman, key members of the JavaTM Platform Performance team. They are the authors of the Java series book JavaTM Platform Performance: Strategies and Tactics. They'll answer your questions about performance. So let's begin. Who has the first question?

Sanny: What kind of performance questions it is ok to ask? Is it general virtual machine performance or AWT, Swing et cetera?

Steve: Sanny: Anything about Java Performance is fair game. I don't promise we'll have answers to everything, but we'll give it a shot.

arnon: Hi - My question is about the current VM's implementation: None of the VMs I have used (only on Windows platforms) seem to be releasing memory back to the system. Thus, if there are "short peaks" of memory usage, they get dragged along for the rest of the process life. Is there a way to release this memory back to the system?

Sanny: What is the difference between the client and server HotSpotTM VM? I understand, in general, that they are the same.

Jeff K.: Arnon -- The Sun classic VM kept heaps it requested from the system until the end of the VM's run. HotSpot will return unused heap to the system, though to keep from thrashing it will wait a bit to see if the memory is really unused. I can't comment on other company's VMs as I don't know their details.

Steve: The client VM and server VM use much of the same technology. However, the Client VM is optimized for quick startup time and low-memory footprint. The server VM is designed for "peak" performance. That means it may use a little more RAM and may take a little longer to get "up-to-speed" but it will go faster in the end.

Jacob2: What is the time cost of making JavaTM Native Interface (JNI) native calls? I see System.arraycopy() is implemented by a native call. Are there cases where it is faster to copy an array in Java code?

Steve: Jacob2: That's a great question. Chapter 9 of our book directly addresses the JNI issue (and specifically arraycopy). You ALWAYS want to use arraycopy. It's really fast. The call is native, but doesn't go through JNI. It is a special hook built into the VM.

jchu: What's the difference between Hashtable and Hashmap, performance wise? Thanks.

Jeff K.: jchu -- Hashmap and Vector were the first collections in java. There are a few differences between hashtable and hashmap. Probably the most important one to you is that Hashtable is fully synchronized while HashMap is not. This means that HashMap is faster, though not thread safe in of itself. (There are ways to make it thread safe.) But also very important is that HashMap implements the Map interface. This allows you to easily substitute OTHER Map implementations in your code. Sometimes a hash isn't the most appropriate algorithm and you might get better performance out of a different Map implementation, such as a Tree.

Jayme Pechan: Is there a way to cache classes locally on a PC and only download classes that have changed (maybe by date/time stamp?) when an application starts up?

Steve: Jayme Pe: With the 1.3 plug-in you can specify that you want applets to be "sticky". You can see how to do this in the plug-in docs. Our book mentions this in chapter 12. Also you should look at JavaTM Web Start, which is a great new technology for deploying web-based applications. It gives you a lot of control over these kinds of issues.

zoltar: What can one do to improve the startup time of an applet, especially in the Java plug-in? 1.3 hasn't seemed to make a lot of difference to us.

Steve: Zoltar: Startup time is always tricky business, but there is lots you can do. One thing is sticky applets (as I mentioned previously). This helps you avoid the download hit. There are also lots of things involving how you handle class loading. Chapter 5 of the book discusses some of these class load related issues. There are some other things you can do. One recent example we saw with a customer, they had put all their classes in jar files, but had put their "resources" (like gif images) on the server as individual files. This meant they made huge numbers of HTTP requests to start up. Chapter 12 of the book discusses some of these deployment issues.

Jacob2: Can we have the info on your book, please (title, publisher, etc.)

Jeff K.: jacob2 -- The book is Java Platform Performance: Strategies and Tactics. Wilson/Kesselman, Addison-Wesley, ISBN 0-201-70969-4. There is a supporting website at that has additional materials, some minor errata, and a link to two sample chapters in the JDCSM.

Rich: What are some of the performance ramifications of an application with a large number of Swing controls, probably similar in context to Microsoft Outlook, and how can some of the perceived performance problems be reduced?

Steve: Rich: Ah, Swing is one of my favorite topics. Having large numbers of Swing controls in a window can be tricky. One of the basic tricks is to control how the components are created. SwingSet2 is a good example of this. It creates a really large number of components, but creates them "asynchronously" so that you don't have to wait for all of them to be created before the app starts. Chapter 11 of our book discusses writing "responsive" Swing applications, and that usually involves threads. Now, on a related topic. if you're using JTable, or JTree you want to be careful how you manage your models and renderers. Lastly, in terms of "brute rendering speed" of Swing components, we're doing a lot of work for 1.4 to speed up Java 2DTM to render Swing GUIs faster.

sansfromage: Hello, I would like to detect when an object is no longer referenced in an application. It seems that we need to launch Garbage Collection to detect it. Is there another method to do this without wasting time in garbage collection ? I need more speed because of a distributed architecture.

Jeff K.: sansfrom -- I think there are multiple parts to your question. In order to know an object isn't referenced you MUST trace the references. This by definition is garbage collection. Now, you can know when the collector has determined an object is a candidate for collection using one of two different reference types. If you create a WeakReference to the object, it will not keep the object from being collected. When the object becomes a candidate for collection, the WeakReference get() method will return null. The other way is with a PhantomReference. A phantom reference effectively "short circuits" the garbage collector. Instead of the collected object being returned to the heap, it is placed on a user defined queue for further processing.

billr: What kind of optimizations does the HotSpot compiler really take? I've only heard about general things that it does. Where can I find more detail? What about future plans?

Steve: Billr: The first thing is that as we previously mentioned, there are two compilers. There are the HotSpot Server and HotSpot Client. However, in general the Server compiler does the more interesting optimizations, the Client compiler does fairly simple optimizations. A lot of the really interesting optimizations that HotSpot does involve things that require "run time" knowledge. One example is "aggressive inlining" where the compiler can inline methods that aren't private, final or static in some cases. Appendix B of the book has a few more details on the types of optimizations HotSpot does.

sansfromage: Ok, but the problem is thatI need to know immediately when the object is no more referenced and I can't wait the GC to be launched (other CORBA processes may access this object)

Jeff K.: sansfrom -- This is a common area of confusion. By definition, the ONLY guarantee the garbage collector gives you is that it will make a best faith effort to reclaim all unused objects before throwing an "out of memory" error. It is free to delay a given object's collection as long as it wants up to that point. So there are no timeliness guarantees at all. If timeliness of detection that an object is unused is important, YOU must track that in your application logic. For this reason it is also imperative that you NOT use finalizers for anything that must be done in a timely manner, like releasing file handles. Appendix A of our book discuss the garbage collection process and what you can and can't expect from it.

arnon: This is stretching the performance issue a bit, but still: JRE1.3 is pretty big - about 20MB, which makes it hard to download, in the case of trying to distribute a Java application (not an applet). Is there a way to reduce that size into something more manageable? Is the JRE going to grow even still in the next version?

Steve: Arnon: The full JDKTM download is about 20 MB. However, the JRE download, which strips away the tools, demos, etc is only about 5 MB. This is still bigger than we'd like, but it's much better than 20. I can't promise anything for 1.4, but we're looking at a number of options to bring this size down below 5 MB (including better compression and things like that). We'll see how it goes.

zoltar: Do you have any tips for RMI performance especially with many concurrent users. Obviously you want to avoid excessive synchronization but are there any other obvious gains here?

Jeff K.: zoltar -- one good place to look for RMI speed improvements is in the serialization of your parameters. In general, primitive types are going to be the fastest, but beyond that people often serialize much more than they have to without realizing it. (This also comes up in Jini and some other technologies that depend on Serialization.) Chapter 4.2 talks about some serialization improvements. That entire chapter is up in the JDC, actually.

Lillian Andres: Hello, I enjoyed your book! I have a brief question on Swing performance. You implied that there may be a need for a concentrator object - to limit the repaint events to once every 100 milliseconds in heavily loaded systems. We have such a system. However, does the latest Swing 1.3 have its own "concentrator" that compacts say repaint requests on the same component?

Steve: Lillian: Great! An actual reader!. You're discussing the chapter that Hans Muller (Swing's tech lead) wrote for us. Swing's RepaintManager class does take care of batching repaints. However, you still want the "concentrator" when working in a multi-threaded environment and possibly more importantly when you update the Swing models events are fired. It often pays off to batch these events (as shown in the ComboBox example in the Model's and Renderers chapter). The reason is that there is some overhead for context switching (using invokeLater) into the AWT-event thread. You want to minimize that.

ChrisRijk: Reference Objects and Garbage Collection has decent information on references and garbage collection:

Jacob2: What does the future look like for Java performance? Will there come a time when Java's performance on things like BigInteger operations can rival the C/C++ libraries that are out there?

Jeff K.: jacob2 -- In general, Java performance is looking very bright for the future. The fact is, that except for a few specific gotchas, Java is performing as well or better than C and C++ today. I'd recommend anyone who is interested in this to go to our web page's "Additional materials" section and follow the link to Chris Rijk's article on Aces hardware. He's an independent (doesn't work for Sun, IBM or any other Java maker) engineer who did a series of benchmark tests of our JavaTM Virtual Machine1, IBM's VM, gcc and MSVC. The results will likely both surprise and please you. The future looks even better. Dynamic compilation is in its infancy. We are already beating static compilers in many areas and we've just scratched the surface of what is possible with run-time analysis driven compilation.

Steve: Jacob2: As for BigInteger, it's worth noting that we rewrote that in from Scratch in 1.3. It used to be based on an industry-standard C library for doing this type of thing. Rewriting it in Java sped it up by a great deal. There are a few "war stories" in the book about this project. Some of the issues had to do with JNITM, others had to do "Object Mutability" which has it's own chapter in the book.

Sanny: Does the speed of garbage collection depend on size of objects or only on their number?

Steve: Sanny: This really gets implementation specific, but I can talk about HotSpot. HotSpot uses a "generational" garbage collector. This means there are different areas of memory for "new" objects and "old" objects. Collection of "new" objects is REALLY fast. The good news is that objects tend to die young. So the direct answer is that "size doesn't matter". However, if you create lots of big objects, you quickly fill the "new" space and they become "old" more quickly which means it takes longer to collect. So, indirectly size does matter. I hope that made sense. There is more info in Appendix B in the book.

Lillian Andres: Steve, you said you still want the 'concentrator' when working in a multi-threaded environment. Why? Isn't it true that the "repaint" request is queued on the EventQueue, and then the RepaintManager compresses those requests. I don't understand why being multi-threaded would require another Concentrator object. What am I missing? Thanks in advance for your patience.

Steve: Lillian: The "repaint" request themselves aren't the issue. If all you're doing is call repaint you're fine. However, you're usually doing something like modifying the Component state. This means that you run into the Context Switching issue (invokeLater) that I mentioned earlier. You also run into the event batching problem (for non repaint events like a TableDataChangedEvent).

Jeff K.: I'd like to mention at this point the importance of analysis and profiling. ALL of our performance work at Sun starts with our ongoing benchmarking. If you try to write all your code "maximally efficiently" all you will end up with are unreadable, untunable code. Some of you may be familiar with the old 80/20 rule -- you spend 80% of your time in 20% of your code. The key to high performance code is organization and process. Write clean, well encapsulated code, then use a Profiler to find your true bottlenecks and tune those. In 15 years of running profilers, I have always been surprised at what my true bottlenecks were.

ChrisRijk: Read my article, Binaries Vs Byte-Codes. However, it does need more work. I hope to update it sometime, but pure Java versus pure C/C++ does work pretty nicely. Very complex subject though.

kschneid: Couple of hprof questions: I know the book talked a bit about using hprof, but do you have any other pointers to detailed info on using it and/or tools that provide a more friendly UI to it? What specific sorts of things can you do with commercial tools (such as OptimizeIt,JProbe, etc.) that you just can't do with hprof? In other words, given some time to learn the details of hprof, what's missing in terms of profiling an application?

Steve: kschneid: Hprof is a pretty powerful tool, but it lacks a lot of control. The commercial tools really give you a great deal of ability to inspect things interactively and carve the data different ways. Somewhere (I don't have the URL) there is a tool called HAT that lets you get a friendly interface on the hprof heap profiler. However, the commercial tools are still nicer. Also, Ed (our moderator) tells me there are a couple of "tech tips" about Hprof posted on the JDC. You might want to look those up. In essence, you can do a lot with Hprof, but it's a big pain.

Martijn: When you load a lot of let's say for example pictures, the Java Virtual Machine usually goes out of memory. Making the heap larger solves this, but not always (depending on how much memory is being used for the objects). Does the JVM make use of swapping? It seems like it doesn't. And if it doesn't why not?

ChrisRijk: To follow up on Jeff's comment on profiling. I've been optimizing a GIF encoder recently. I had thought that the biggest problem was the actual compression part, but it turned out that 80-90% of the time was actually being spent in the first stage - reading the binary data and setting up the colour table. So I re-wrote that section - and improved performance by about 5-8 fold. Pretty nice for a few hours work.

Jeff K.: Martijn: The Sun JVMs have a minimum and maximum heap size, that is settable through command line parameters. The maximum exists in order to give the system administrator control over how much in the way of memory resources the JVM will consume. This is important in production environments. The JVM will attempt to get from the operating system a heap up to the maximum you have set. In an OS that supports swapping, you can set the max larger than the physical memory available and the system will swap underneath you to make it available. The current absolute maximum Java heap size is about 2 gigabytes (due to internals having to do with addressing.)

Sanny: So, "new" area is limited by size, not by number of objects or their creation time?

Steve: Sanny: Yes, that's exactly right.

zoltar: Why do most Java VM's impose an artificial memory ceiling (i.e. -Xmx64M)? Why can't the VM use available memory like a regular native process?

Jeff K.: zoltar -- I think I just answered that as part of my last answer, if it is still unclear, could you rephrase the question?

Lillian Andres: Steve: Thank you. Your answer now makes sense. Basically because my component's state is changing (constantly) - I want to avoid excessive context switching and I hadn't even considered the table change events. Thank you. Also, as always our management bought profiling tools - but not on the target/deployment platform! Thanks again for your input.

Steve: Hi All: It's looks like we're going to wrap this up pretty soon. I'd like to thank everyone for coming today. We're really glad you all came. I think we got some really great questions. I really encourage everyone to check out the book chapters we posted on the JDC. Also, if you have comments on anything feel free to ping us at (jpp-book@eng.sun.com).

Trevor: In your book about profiling, you're generally talking about applications. What about heap profiling applets running in the 1.2 plug-in? Is it possible or do I have to profile the applets as applications (other than putting in my own timing and heap tracing)? Thanks!

Jeff K.: Trevor: Most of the commercial Profiling tools will handle Applets just fine. We have a list of links to those, most of which have free trial versions, on our web page in the "Tools" section.

EdO: Well our hour has drawn quickly to a close. There have been a lot of excellent questions. I want to thank all of our participants, and especially our guests, Steve and Jeff.

Steve: Thanks again for all the great questions everyone. I hope you all got something out of this. As I said earlier, if you have questions about the book (or any of the things we discussed in this chat) feel free to ping Jeff and I at (jpp-book@eng.sun.com).

Jeff K.: Thanks for coming, all. Great questions :)

EdO: Last moderator (me) signing off. The forum is now unmoderated.

Also, see two chapters from JavaTM Platform Performance:Strategies and Tactics and the Java Programming forum.

coffeecup


Reader Feedback

Tell us what you think of this transcript.

Duke

Very worth reading Worth reading Not worth reading

If you have other comments or ideas for future articles, please type them here

_______
1 As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.


Print Button
[ This page was updated: 21-Sep-2000 ]
Products & APIs | Developer Connection | Docs & Training | Online Support
Community Discussion | Industry News | Solutions Marketplace | Case Studies
Glossary | Feedback | A-Z Index
For more information on Java technology
and other software from Sun Microsystems, call:
(800) 786-7638
Outside the U.S. and Canada, dial your country's AT&T Direct Access Number first.
Sun Microsystems, Inc.
Copyright © 1995-2000 Sun Microsystems, Inc.
All Rights Reserved. Terms of Use. Privacy Policy.