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.lev...@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 > >
