<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">
<p>Hello Archie, thanks for the reply.<br>
</p>
<p>Le 2024-07-09 à 18 h 17, Archie Cobbs a écrit :</p>
</div>
<blockquote type="cite"
cite="mid:CANSoFxum0QcMpjxTXi3NckN3Eo4t_pubabss7Gm0ixyCGmWVBw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">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</div>
</blockquote>
<p>No, in the previous JDK implementation, no 128 kb transfer buffer
was used. The implementation before commit 5cacf21 (September
2023) was as below:</p>
<blockquote>
<pre>public synchronized long transferTo(OutputStream out) throws IOException {
int len = count - pos;
out.write(buf, pos, len);
pos = count;
return len;
}
</pre>
</blockquote>
<p>In above code, <font face="monospace">buf</font> is a protected
field of <font face="monospace">ByteArrayInputStream</font> with
a value specified by user at construction time, so the array can
have any size. I was using a custom <font face="monospace">OutputStream</font>
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 <font face="monospace">ByteBuffer</font> would
make possible to continue to avoid a copy.<br>
</p>
<p> Martin</p>
<p><br>
</p>
</body>
</html>