sun.nio.ch.Util: Don't cache an unlimited amount of memory
Evan Jones
ej at evanjones.ca
Wed Dec 30 14:49:19 UTC 2015
On Tue, Dec 29, 2015 at 11:57 AM, Ariel Weisberg <ariel at weisberg.ws> wrote:
> My intuition is that something based on breaking down IOs is not going o
> pass muster, but it exists.
>
This would probably be ideal, but I'd be worried about changing the
application semantics. This would definitely be a more invasive change, so
I'm not about to attempt that.
Could this be handled better with a different pooling approach that is not
> per thread over some threshold? There are a bunch of permutations that
> could trade off allocation/deallocation for concurrency vs. blocking
> threads waiting for operations to complete freeing up globally pooled
> buffers to bound peak footprint.
>
This is starting to feel like implementing malloc() :)
Seriously though: this is another reasonable proposal that would achieve my
goal of preventing others from being surprised by enormous native memory
usage due to this issue. I have a bit of time available to attempt to write
a patch. If an OpenJDK committer is interested in helping figure out a fix,
I'd be happy to help. Current proposals:
1. Naive per-thread limit (I think this is a better trade-off than the
current version, but will have a small CPU cost for I/Os larger than the
limit)
2. Estimate recent "max usage" and shrink to fit: Probably a superior
solution, but will be more complex.
3. Combination of per-thread cache, plus possibly a global cache for big
buffers or something similar? I'm not 100% sure what parameters would make
sense here.
--
Evan Jones
http://evanjones.ca/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20151230/6fecc6f7/attachment.html>
More information about the nio-dev
mailing list