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 | tprinte...@twitter.com On June 22, 2018 at 7:11:05 AM, Alan Bateman (alan.bate...@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
