Promptly freeing the per-thread cached direct buffers when a thread exits

[Tony Printezis]

Can I also add that, when a buffer in the cache needs to be replaced with a
new (and typically larger) one, the old buffer is explicitly freed. So, the
code already assumes that buffers that are in the cache should not be
reachable from anywhere else. Explicitly freeing them when the thread exits
is consistent (IMHO) with this behavior.

Tony

—————
Tony Printezis | @TonyPrintezis | tprintezis at twitter.com


On June 22, 2018 at 7:11:05 AM, Alan Bateman (alan.bateman at oracle.com)
wrote:

On 21/06/2018 21:13, Florian Weimer wrote:
> * Tony Printezis:
>
>> There are a few obvious ways to mitigate this, e.g., cause a Full GC /
>> concurrent GC cycle at regular intervals. However, the best solution
IMHO
>> is to explicitly free any direct buffers that are still in the cache
when a
>> thread exits.
> Why is this safe? Couldn't these direct byte buffers be used with a
> custom channel that leaks them to another thread?
The temporary direct buffer mechanism is internal to java.base so it
should never be used with custom channel implementations. There may be
some pre-existing issues with the FileChannel transferXXX methods when
called with an untrusted source/sink that will need to be audited but
this is not something that I can discuss on this mailing list.

-Alan