What is the mystery with UNIXProcessReaper??

Question

I am making this post partially to actually get its name on to the net (Google has zero hits on UNIXProcessReaper) but mainly to garner some insight into a major problem I have "sort of" solved. OK, so I'm a Java newbee, having to maintain a bunch of dodgy Java code running on Linux (Redhat 7.2) with Java 2 Runtime Environment, Standard Edition (build 1.4.0-b92), Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode).
Typically the application chews up about 2 - 4% of the cpu when running. I re-wrote the logging facility and (stupidly it seems) removed the BufferedOutputStream from the file I/O, which caused the application to go crazy, sitting on 100% of cpu usage for 5 to 10 seconds at a time. Note that the total logging load would not be more than 300 bytes / second.
The mystery for me is that the profiler showed the following activity during these spasms:
CPU SAMPLES BEGIN (total = 117209) Mon Oct 21 16:43:23 2002
rank self accum count trace method
1 32.74% 32.74% 47417 4636 java.lang.UNIXProcessReaper.run
2 32.73% 65.47% 47907 3227 sun.awt.motif.MToolkit.run
3 1.64% 67.11% 1922 30291 sun.awt.font.FontDesignMetrics.handleCharWidth
4 0.32% 67.43% 370 30187 sun.awt.font.NativeFontWrapper.getCharMetrics
5 0.24% 67.67% 285 30292 javax.swing.plaf.basic.BasicLabelUI.getPreferredSize
6 0.23% 67.90% 271 30284 sun.awt.SunToolkit.getFontMetrics
7 0.22% 68.13% 261 30285 java.awt.font.FontRenderContext.getTransform
8 0.22% 68.34% 254 30286 sun.awt.font.FontDesignMetrics.<init>
but nothing gives me any help on UNIXProcessReaper, it is not mentioned in any Java documentation, and as I started out saying, it has zero hits on Google. I guess it is (or part of) the garbage collector. BTW, my intuition tells me the application has some other fundamental problem lying just under the surface, probably to do with how it uses swing, and I just dug deep enough to expose it.
Can anyone shed any light on why unbuffered I/O would cause such problems and why the UNIXProcessReaper has not been mentioned by any other lost newbee?
Cheers,
Scott.

Answer 1

From the docs :
"By setting up such an output stream, an application can write bytes to the underlying output stream without necessarily causing a call to the underlying system for each byte written. The data is written into an internal buffer, and then written to the underlying stream if the buffer reaches its capacity, the buffer output stream is closed, or the buffer output stream is explicitly flushed. "
So this means that unnecessary calls are removed during writting. Instead of making multiple writes when you receive data, a write is only done when the buffer is full. That's why it is more efficient. The java tutorial also states this in this url : http://java.sun.com/docs/books/tutorial/essential/io/datasinks.html
If you are a newbie who is worried too much about logging, I'd suggest you take a look at the log4j project. Check it out at
http://jakarta.apache.org