Letters to the Editor

Quite a few readers responded to last month's JDK 1.2 bug report with skepticism at best; author Kieron Murphy takes on the critics. Plus: VolanoMark's John Neffenger addresses a mailbag full of JVM scalability queries; Merlin Hughes tackles the mathematical intricacies of 3D programming in Java; Allen Holub defends his approach to coding; and technical Q&A with Chuck McManis, Todd Sundsted, Bill Venners, and John Zukowski

1 2 3 4 Page 2
Page 2 of 4

Getting around file-descriptor limits


It wasn't clear exactly which platforms you were achieving 2000, 2400 and even 4096 connections on. My understanding is that Solaris has a file-descriptor limit of 1024 connections and that to achieve higher numbers you would have to recompile the kernel. Is this how you achieved those figures or has Solaris 2.6 raised the maximum limit?

Any information on how to go about getting more than 1024 connections will be greatly appreciated.

Andreas Walsh

Andreas, I've seen up to 2000 (and heard of up to 2400) connections on Solaris 2.6. See the sections for FreeBSD, Linux, and Solaris at: Server Tips and Tricks: http://www.volano.net/guide/tips.html Here you'll find information on how I increased the file descriptors on each of these systems. Only Linux requires you to rebuild the kernel. In fact, you can change the settings for FreeBSD on the fly. Windows NT has no per-process file descriptor limit (or if it does, it's around 32,000), but it does have per-process thread limits (which I discuss in the article). John Neffenger

Client-side performance


I have a question about your test application, VolanoMark. Does this client simulate up to 900 sessions in a single application? If so, were you not hitting CPU or I/O limits on the client platform? Given that the test application was also running on a JVM, it seems to me that you were measuring performance of the client and server -- not just the server.

Michael Lee

Michael, In almost all cases, the server-side (responder) Java VM was slower than the client-side (initiator) Java VM, resulting in 100-percent CPU usage for the server and much less than full CPU usage for the client. I wanted to run the tests with exactly the same client Java VM, so I chose the fastest and most stable JVM that could make it to 900 connections (Microsoft SDK for Java 3.0, for now). It would have been interesting to run the vendors against themselves -- the Linux OS and JDK on both sides, for example -- but then I wouldn't have been driving the server as fast as possible. It would also have been nice to "gang up" on the server machine by driving it with several client machines, but that takes a distributed coordination among the client applications, which doesn't yet exist in VolanoMark. Maybe VolanoMark 3.0. In any case, the SPEC group likes to keep hardware requirements to a minimum for its benchmarks -- one or two machines max. I ran the local loopback test precisely to avoid the effects of any bottlenecks such as the client machine or even the network connection itself. To make clear distinctions between the connection scalability of the fastest Java virtual machines, though, I think the choice is either to run the test driver on a much faster machine than the server or to coordinate multiple test driver applications from multiple machines. John Neffenger

Kaffe Open -- time for another look?


I enjoyed reading your benchmarking of various JDKs. One JDK that appears to have been overlooked, due to its very recent release perhaps, is Kaffe Open (http://www.transvirtual.com/). It is a JIT compiler, from what I understand.

William Burrow

William, I tried off and on for a long time to get Kaffe to run our VolanoChat product, but I never managed to get very far. If I remember correctly, I tried it on Windows NT, FreeBSD, BSDI, Linux, and Solaris. I gave up about a year ago. It just wasn't at all stable, and I couldn't get more than a dozen or so connections. I'm sure all that has changed by now, so I'm eager to give it a try in the next round. John Neffenger

IBM JDK 1.1.7 on the horizon


I just read your latest article in JavaWorld. Thanks for the nice words about IBM's JDK. I'm a little confused about the following:

IBM's recent updates to its operating system, TCP/IP stack, and JVM have given it a huge 50-percent performance improvement over the VolanoMark 2.0 tests I ran without the updates, but I could not get more than 400 concurrent connections with IBM's JVM.

However, later in the article, you write:

IBM JDK 1.1.6
  • IBM OS/2 Warp 4.00 FixPak 7 (Revision 9.031)
  • IBM TCP/IP Version 4.1 (SOCKETS.SYS: 5.3003, AFOS2.SYS: 5.3000, AFINET.SYS:> 5.3002)
  • IBM JDK Version "JDK 1.1.6 IBM build o116-19980605 (JIT: javax)"
  • Set THREADS=4096 in CONFIG.SYS.

This suggests that you did run with the updates.

We have made significant progress even since the 1.1.6 release. Expect the next crank of Java, 1.1.7, to be greatly improved on OS/2 both in throughput (more tuning and a better JIT) as well as more concurrent connections. Some of these changes may even make it into the 1.1.6 service stream.

Rajiv Arora Senior Software Engineer NCSD System Performance

Rajiv, I did run with the updates. My 50-percent improvement remark was comparing the score I got without the updates (780): http://www.volano.com/spec/index.html against the new score with the udpates (1216): http://www.javaworld.com/javaworld/jw-08-1998/jw-08-volanomark.html (Actually a 56-percent improvement, assuming I divided correctly.) I didn't publish the scores without the updates, but that might be unclear from the text. I'm glad to hear about the new improvements coming along! John Neffenger

Benchmark results: testing for pure speed


I am wondering if the benchmarks are being skewed in any funny way as a result of having a single client machine. Have you run the tests with multiple client machines accessing the server? What are the results like? Were you ever CPU-bound on the server? On the client? I'd like to run the test with multiple client machines, each with a couple of hundred users.

Brad Hlista

Brad, As far as I can figure, the benchmark results on the network test are "skewed" in that the fastest Java virtual machines may have their scores dampened by the speed of the machine driving the test and the speed of the network itself. Such an effect is apparent when comparing the chart of the current Java VMs, where there is a wide variation in speed, with the results of the unreleased Java VMs, where all of them are fast. I have run with multiple clients, but to get a common score I need to enable the message counting on the server side, which affects the performance by about 5 percent and doesn't give a definitive score. To do it right, I need to modify the test driver (client side) to coordinate among multiple Java applications, perhaps on different machines. I'm afraid that, in an attempt to drive the system under test by several other machines on the network, I might just end up testing the speed of the network itself. That's why I test for pure speed using the loopback test with common hardware. Don't forget -- I'm not trying to set a speed record between two systems. In running the tests, I'm trying to find out if there are any huge differences in performance, scalability, and stability in the Java virtual machines. In fact, there are. But those differences are diminishing with the next batch of Java VMs arriving this fall. John Neffenger

Java Step by Step: 3D Graphic Java Series by Merlin Hughes


The need for speed


First let me say that I've enjoyed especially your last two 3D columns in JavaWorld; I'll be using information from them in the very near future (meaning I should have done it yesterday). Anyhow, I'm doing a project with Java and I have a problem. The problem is huge, but the solution -- if there is one -- shouldn't be. I have 3D MRI-data. The size is 256 x 256 x 256 pixels (or voxels). From that data I take 2D slices from different locations and different directions. The data is stored in either int[][][] or byte[][][]. (It's grayscale, but at some point I need to add color -- either on the fly or by converting data to RGB.) I have three simultaneous views to this data. Each view will ask for a slice, which the data will provide. The code is as follows:

 public Image getSliceY(int
                                       int[] imageData;
                                       imageData = new int[sizeX * sizeZ];
                                       for (int k ....
                                       imageData[index++] = voxels[k][Y][i];
                                       return Toolkit.getDefaultToolkit().createImage(new
                                       MemoryImageSource(sizeX, sizeZ, imageData, 0, sizeX));

No problems yet. This works. The problem is, this is slow, and it takes a lot of memory. It's bearable with 3D image data of size 128 x 128 x 84 (the slices will be 128 x 128 or 128 x 84) on a 96-MB Pentium 166 and WinNT with Microsoft JViews (the fastest VM I have). But with the full images ... I just can't do it.

The solution? Well, that's what I come to you for. I've searched the Net and I haven't found any other way. Everybody uses createImage, but that doesn't seem to work. The process is too slow. I'm a bit surprised, because I'd imagine in doing animation one would have to use something faster.

Hugo Gavert

Hugo, I don't have a complete answer to your question because the image stuff is all beneath the JVM and addressing memory problems and speed issues down there is hard. However, there is a new (as of JDK 1.1) MemoryImageSource method that may resolve some of your problems. Basically, create your imageData array once. Then create your MemoryImageSource attached to that. Then call memoryImageSource.setAnimated (true). Then create your image. Then, each time you update your view, fill in the initial image data array; don't change your MemoryImageSource or your image; just call memoryImageSource.newPixels (). This will recreate the Image and automatically refresh your display. If you examine the source to either of the articles, you'll see that I do just this. In your case, you'll obviously want to have three image data arrays, sources, and images, but the extension should be fairly easy. Hopefully this will sort out some of your problems. Another thing; when you're finished with an Image, call its flush() method; this frees up some resources. The ultimate answer is that using the JDK 1.1 Image framework isn't ideal for speed. It is possible that the JDK 1.2 Java2D or Java3D APIs may provide a solution; you may be able to more rapidly create a texture map and draw textured polygons or some-such. Have a look at those APIs. The problem here would be that your speed would be hardware-dependent; hardware with a limited CPU-texture bus wouldn't like your application. But it may be better than nothing. Merlin Hughes

How did you do that?


Great series on 3D graphics in Java! Your articles have really helped solidify my scattered knowledge of 3D graphics, shadowing, etc. Is the source code for the 3D planetary surface available? No matter how I tweak your example code, I get nothing that approaches your example image.

Mike Shipkowski

Mike, It's a bit convoluted to get from the example code to the code that produced the first image. (I created the image with a beta version of the code.) The following steps should get you there:

1 2 3 4 Page 2
Page 2 of 4