RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v2]
Alan Bateman
alanb at openjdk.org
Wed Jul 26 09:32:43 UTC 2023
On Tue, 25 Jul 2023 23:50:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:
>> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.
>
> Brian Burkhalter has updated the pull request incrementally with three additional commits since the last revision:
>
> - 6478546: Decrease malloc limit to 1.5 MB
> - 6478546: Minor refactoring
> - 6478546: Prevent short read
I looked through the latest version (69941de4).
I think the main issue with this version is that it changes behavior of the read methods to work like "read fully", I don't think we should do that. To preserve long standing behavior it should attempt a second/subsequent read when the clamped buffer is filled. I think this is close to what you want here:
private int readBytes(byte[] b, final int off, int len) throws IOException {
Objects.checkFromIndexSize(off, len, b.length);
int nread = 0;
int pos = off;
int remaining = len;
do {
int size = Math.min(remaining, 64 * 1024);
try {
int n = readBytes0(b, pos, size);
if (n < 0) {
// EOF
break;
}
nread += n;
if (n < size) {
// buffer not filled
break;
}
pos += n;
remaining -= n;
} catch (IOException ioe) {
if (nread > 0) {
break;
}
throw ioe;
}
} while (remaining > 0);
return nread;
}
The changes in 69941de4 are also using nested blockers, this is benign, but if this code is change then they can be dropped from the callers.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14981#issuecomment-1651352313
More information about the core-libs-dev
mailing list