Hello Archie, thanks for the reply.
Le 2024-07-09 à 18 h 17, Archie Cobbs a écrit :
The difference in the old vs. new behavior is the use of a 128k
temporary transfer buffer. So if I understand this correctly the
performance problem you are addressing (in terms of blown cache) is
not proportional to the size of the original BLOB, but to at most 128K
No, in the previous JDK implementation, no 128 kb transfer buffer was
used. The implementation before commit 5cacf21 (September 2023) was as
below:
public synchronized long transferTo(OutputStream out) throws IOException {
int len = count - pos;
out.write(buf, pos, len);
pos = count;
return len;
}
In above code, buf is a protected field of ByteArrayInputStream with a
value specified by user at construction time, so the array can have any
size. I was using a custom OutputStream implementation for getting the
value of that field, avoiding any form of copy. But this trick does not
work anymore since a transfer buffer has been introduced in commit
b0d1450 (December 2023). A read-only ByteBuffer would make possible to
continue to avoid a copy.
Martin
