EVALUATION
There are two issues here. One involves the documentation for the
ImageReader.reset() method. The spec for this method is rather vague, and
should be updated to say that it is important for developers to call reset()
after each iteration if they are reusing the same ImageReader to read multiple
images.
The second issue is that we seem to be leaking resources in the JPEGImageReader
(and presumably the JPEGImageWriter as well) if the developer does not
explicitly call reset() between successive reads. This is due to the fact that
we create a new global JNI reference to the temporary pixel buffer without
ever deleting that ref when we're done with it. This means we keep a
reference to a DataBuffer (as the submitter mentioned) that never gets garbage
collected. We can fix this by checking for a non-null pixel buffer object
in setPixelBuffer() (imageioJPEG.c, line 263), and if it is non-null, delete
the existing global ref before we create a new one. Perhaps we could simply
call resetPixelBuffer() as the first step in setPixelBuffer().
(The submitter should be aware that it is important to call reset() if you are
reusing an ImageReader/Writer. I understand that the submitter is avoiding
this call because it is invoking System.gc(), but we are working to remove
the explicit gc() calls as part of the fixes for 4867874 and 4827358.)
###@###.### 2003-05-23
The above evaluation was a little premature on my part. After looking over
the spec a bit more, it becomes clear that a call to setInput/Output() should
reset any internal state so as to avoid leaking native resources. So the
attached testcase should work as written (without an explicit reset() call
between each iteration. Sorry for the confusion.
The fix suggested above would work, but a more complete solution would be to
reset the appropriate internal state when setInput/Output() is called. In
other words, the reset() and setInput/Output() methods should just share a
method that resets internal resources. This will avoid leaking the
DataBuffer objects mentioned earlier. This work would best be completed
alongside the fixes for 4867874 and 4827358.
###@###.### 2003-08-26
|