Hey folks,
I'm working on reducing heap usage of a big server application that
currently holds on to tens of millions of generated FlatBuffer instances in
the old generation. Each such instance looks more or less like this:
private static class FileDesc {
private final ByteBuffer bb;
int bbPos;
FileDesc(ByteBuffer bb) {
bbPos = bb.getShort(bb.position()) + bb.position();
this.bb = bb;
}
public int getVal() {
return bb.getInt(bbPos);
}
}
(I've simplified the code, but the important bit is the ByteBuffer member
and the fact that it provides nice accessors which read data from various
parts of the buffer)
Unfortunately, the heap usage of these buffers adds up quite a bit -- each
ByteBuffer takes 56 bytes of heap, and each 'FileDesc' takes 32 bytes after
padding. The underlying buffers themselves are typically on the order of
100 bytes, so it seems like almost 50% of the heap is being used by wrapper
objects instead of the underlying data itself. Additionally, 2/3 of the
object count are overhead, which I imagine contributes to GC
scanning/marking time.
In practice, all of the ByteBuffers used by this app are simply
ByteBuffer.wrap(byteArray). I was figuring that an easy improvement here
would be to simply store the byte[] and whenever we need to access the
contents of the FlatBuffer, use it as a flyweight:
new FileDesc(ByteBuffer.wrap(byteArray)).getVal();
... and let the magic of Escape Analysis eliminate those allocations.
Unfortunately, I've learned from this group that magic should be tested, so
I wrote a JMH benchmark:
https://gist.github.com/4b6ddf0febcc3620ccdf68e5f11c6c83 and found that the
ByteBuffer.wrap allocation is not eliminated.
Has anyone faced this issue before? It seems like my only real option here
is to modify the flatbuffer code generator to generate byte[] members
instead of ByteBuffer members, so that the flyweight allocation would be
eliminated, but maybe I missed something more clever.
-Todd
--
You received this message because you are subscribed to the Google Groups
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
