|
||||||||
|
|
![]() |
|
|
|
|
||
|
Customizing the WDSc JVM Hey, David: We are starting on our first major Java project and went with WDSc 5.0 for our IDE. We will be working on the project for about six months and will not be able to switch IDEs once we get started. The consultant on the project recommended that we consider Eclipse because it meets the project's requirements and is easier to install. He also said the ability to run Eclipse with a 1.4 JDK is an advantage because it offers better debugging support and matches our iSeries deployment environment. We went with WDSc because it supports CL, DDS, and RPG. I trust our consultant, but I don't understand why the JDK changes debugging. --Travis Java is evolving quickly, and new features are being added all the time. Because of this, every new JDK version offers some compelling new features. One of the compelling features included with 1.4 JDKs is the capability to hot-swap changes made during debugging. That means you can use the debugger to step into a piece of code, change that code, recompile the code, and continue debugging using the changed code. Along with compelling new features, each new version of Java adds performance improvements. By default, WDSc (WebSphere Development Studio client) uses IBM's 1.3.1 JDK for Windows. When it was released, IBM's 1.3.1 JDK was much faster than anything Sun had to offer. Since IBM released its 1.3.1 JDK, Sun Microsystems released its 1.4 JDK, along with several revisions. I use WDSc daily and was happy with IBM's default JDK. Your message prompted me to try running WDSc with Sun's 1.4 JDK. Based on some prior experience I had while profiling Web sites running on Sun's JDK, I was able to get WDSc to start more quickly and to run a little faster on my development system. As a bonus I get the benefit of hot-swap debugging. Here are the steps I followed. First, I removed the vmargs setting from the wdsc.ini and wsappdev.ini files. Before you change those files, make a backup; I copied mine to wdsc.bak and wsappdev.bak. On my system, those files were installed in C:\Program Files\IBM\Websphere Studio. The next thing I did was download and install Sun's latest 1.4.1 JDK, which was 1.4.1_05 when I wrote this. I also tried running Eclipse with Sun's 1.4.2 and 1.4.2_02 JDKs, but WDSc received an error during startup. After I installed Sun's JDK, I changed the start menu option that starts WDSc. To change the option, I right-clicked it and selected Properties. Next, I added the following parameters to the end of the target string: -vm C:\java\sdk\j2sdk1.4.1_05\bin\javaw.exe -vmargs -Xverify:none -Xoptimize -Xms128m –Xmx384m These options tell WDSc to use the Java Virtual Machine (JVM) that is specified with the startup options that follow -vmargs. In this case, the -Xverify:none option tells the JVM to skip byte-code verification, which offers a significant performance improvement with little risk in a stand-alone environment. The -server option tells the JVM to use the server mode Java compiler. I have found that server mode offers more consistent performance with fewer pauses for longer running jobs. The -Xms and -Xmx options set up the minimum and maximum heap sizes allocated to the JVM. The memory options are very important and have the most impact on garbage collection. I find a ratio of about 1 to 3 works well, and set the maximum allocation to the smallest size that will safely prevent out-of-memory errors. There are quite a few other JVM startup options you can try that are described on Sun's Java performance site. The only way to find out what will work in your environment is to test. I have tried all of the various garbage collectors and garbage-collection settings and have found that on a single-processor system, the default garbage collector with reasonable minimum and maximum heap sizes worked best. If you decide to experiment, and find something that works well, let me know, so we can share your discoveries. --David
|
Editors
Contact the Editors |
| Copyright © 1996-2008 Guild Companies, Inc. All Rights Reserved. |