RFR - 6857566 (bf) DirectByteBuffer garbage creation can outpace reclamation

[Benedict Elliott Smith]

Hi,

On the topic of DirectByteBuffer, I encountered a slightly less extreme -
but important if there are many floating around - memory issue that would
be nice to clean up:

When you duplicate() or slice() a DBB the att field is always set to the
buffer you duplicated/sliced from. In some cases (e.g. a duplicate()
followed by a slice()) this means you keep DBBs around that exist only in a
chain linking to the original buffer. It seems that it would be preferable
to directly reference the parent's att if it is not null, and the parent
itself otherwise, as the memory cost mounts up if you create a lot of small
slices from a larger buffer.


On 5 February 2014 08:08, Peter Levart <peter.levart at gmail.com> wrote:

> Hi,
>
> I'm proposing a patch for the following issue:
>
>     https://bugs.openjdk.java.net/browse/JDK-6857566
>
> The patch is basically the same as developed and tested as part of the
> following discussion 3 months ago:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-
> October/021547.html
>
> It's just modified to be applied on top of JDK9 which already changed
> since then. Here's the webrev:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/DirectBufferAlloc/webrev.01/
>
>
> As Alan Bateman pointed out: "A related piece of work is the FileChannel
> map implementation where there is a gc + retry if mmap fails. This could be
> changed to have a similar back-off/retry."
>
> I'm planning to examine this code and come up with a similar patch for
> mapped memory.
>
> Regards, Peter
>
>