11

So the Java NIO architects didn't make a ByteBuffer interface, but rather a ByteBuffer class, which isn't a final class, but it has no package-public constructors, and therefore it can't be subclassed outside of its package. Phooey. :P

I have a program that uses memory-mapped file byte buffers (obtained via FileChannel.map()) in a bunch of places, and I'm trying to track down a nasty bug where the file in question is left open because there is at least one ByteBuffer that isn't released to garbage collection.

I would like to create an InstrumentedByteBuffer class that looks like a byte buffer, but decorates a regular ByteBuffer (or its subclasses e.g. MappedByteBuffer) and keeps track of its existence (including new buffers created by duplicate() and slice()) -- that way I can keep my code intact that uses the ByteBuffer, I just have to decorate the original byte buffer.

Is there any way to do this (via reflection or proxies or whatever) to get around the private constructors? I don't need to ship this into a final product, I just need to use it temporarily to solve this bug.

Jason S
  • 184,598
  • 164
  • 608
  • 970
  • I wonder if a tool like `YourKit`, with its memory debugger and probes, might be able to help you track down the stray object (I use `YourKit` a lot, but never had to debug an issue like this one). – NPE Oct 10 '11 at 17:36
  • 2
    Also, I am not sure how subclassing would help, given that you don't control the creation of the buffer. You say that you use `FileChannel.map()`, so you'd somehow need to coax the latter into creating an instance of your class instead, no? – NPE Oct 10 '11 at 17:48
  • Can you dump the heap & trace through the references to your rogue instance? – jtoberon Oct 10 '11 at 18:03
  • @aix: I have control (well, I'm the one who wrote the function that calls FileChannel.map()) over the initial creation of the buffer, it's just that I end up using it in several dozen places, any one of which could be slice()d and stashed away as a private variable. – Jason S Oct 10 '11 at 18:12
  • ByteBuffer is built with performance in mind, and rightfully so. – bestsss Oct 11 '11 at 15:04
  • there you go: http://stackoverflow.com/questions/624458/extending-bytebuffer-class ; subclassing won't do what you need, though – bestsss Oct 11 '11 at 15:06
  • @bestssss: thanks -- voting to close as duplicate. – Jason S Oct 11 '11 at 15:17

5 Answers5

2

I'm trying to track down a nasty bug where the file in question is left open because there is at least one ByteBuffer that isn't released to garbage collection

That doesn't make sense. An uncollected ByteBuffer won't stop a file being closed. You're barking up the wrong tree here. However there is a well-known problem with MappedByteBuffer whereby it is never garbage-collected, keeping the file effectively open. It's really a design problem: it has been known about for years but there is no real solution. The moral is don't use large numbers of MappedByteBuffers.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • 1
    @Jason S But you kept talking about subclassing ByteBuffers, which aren't the problem. Subclassing them won't make any difference. It's the *Mapped* ByteBuffers. The mapped data area never gets released even if the MBB itself gets garbage-collected. And, as I said, there is no solution. – user207421 Oct 11 '11 at 05:25
  • you miss the point: I don't care about the class I'm subclassing; I care about being able to substitute my instrumented class for another class. (so it wouldn't be an issue if they had made a ByteBuffer interface) I want to create a class that I can delegate its methods to the real `MappedByteBuffer`, but intercept `slice()` and `duplicate()` and `asReadOnlyBuffer()` so I can decorate those buffers as well, and then use my class where my functions expect a ByteBuffer. – Jason S Oct 11 '11 at 11:50
  • ...and for what it's worth, on my PC, Java *does* consistently release the file when the MappedByteBuffer gets garbage-collected. (but I'm using read-only mode; if it has problems with read-write mode that doesn't affect me) – Jason S Oct 11 '11 at 11:53
  • @JasonS So is somebody or something stopping you doing that? ByteBuffer is an abstract class: just extend it. – user207421 Feb 27 '13 at 12:24
2

JMockit provides a convenient way of creating a mocked class. It may be of help in this case.

Mock the methods you are interested in, and let them do your bookkeeping and then call the original class' method.

Community
  • 1
  • 1
KarlP
  • 5,149
  • 2
  • 28
  • 41
1

I think you are on the wrong track. FileChannel.map() is broken by design because its limited to 2GB chunks and you can't control when the mapping should get picked up by the garbage collection. On Windows, this is a frequent cause for the application not being able to open the mapped file again.

So instead of making things even worse with byte code instruction or similar hacks, you should refactor your code to get rid of FileChannel.map(). The next programmer who has to maintain your code will be very thankful if you did. ;-)

Christian Schlichtherle
  • 3,125
  • 1
  • 23
  • 47
-1

I don't see why you need to subclass here. Why not use AOP? AspectJ seems perfect for the job. If you're really feeling ambitious, use Java Instrumentation and do some byte code engineering :P

alphazero
  • 27,094
  • 3
  • 30
  • 26
-1

Hmm -- I just ran across this: the JavaSpecialists newsletter 168 seems like it can produce a general-purpose delegation framework -- if a bit slow due to reflection.

Socket uses the strategy pattern for the actual communication and we are able to specify our own implementation. Thus all we would need to do is write our own strategy that counts the bytes flowing backwards and forwards. Unfortunately the standard strategy implementations are package access in the java.net.* package, so we are not able to use them directly. We certainly cannot subclass them, but we could call the methods with reflection. However, because the classes themselves are package access, we need to find the declared constructor, set that to be accessible and then instantiate it.

Jason S
  • 184,598
  • 164
  • 608
  • 970
  • The main issue w/ calling package private methods is that they may suddenly change, also it might be a non-portable solution across JVMs. Some invariants may be not be honored. Yet, if you just need to unmap() you might consider calling the cleaner. However I'd address how to track the issue w/ slice(), etc. – bestsss Oct 17 '11 at 21:48
  • Take a memory dump and find all DirectByteBuffer(s) that have the same address as the problematic one, then check who keeps references to and you will resolve the problem. – bestsss Oct 17 '11 at 21:49