From what I recall the last time I looked at the source code for WorkerThreadImpl, there are ByteBuffer's for each connection in order to handle partial reads. For instance, there needs to be enough buffer space for all the incoming and outgoing HTTP headers and it needs to buffer until they are all read. It also gets more complex when there is SSL involved to handle partial SSL read/decode operations.
You may have to dig into the source code for the grizzly version that's used in your rev of Glassfish, but I think there's an option in there to have *1* big ByteBuffer that acts as a master and then have each connection's buffer be a slice of the master. I also think there's an option to control the initial size of each connection's IO buffers.
Not sure if any of this helps, but it may be necessary to spend some time in the grizzly/glassfish source to see where these allocations happen and how to tune them. Pretty sure they are tune-able.
https://grizzly.dev.java.net/nonav/xref/index.html
[Message sent by forum member 'djhagberg' (dhagberg_at_millibits.com)]
http://forums.java.net/jive/thread.jspa?messageID=381773