[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on JGRP-1989: --------------------------------------- {quote}Even the most light-weight impl adds ~16 bytes to every message, and I'm not willing to add that cost.{quote} Let me clarify why I returned to that idea, and why I think you should take a second look at it too, especially after this interesting reuse opportunities which you have found. By abstracting the "buffer type" into some more abstract JGroups specific contract, one would be able to replace these reusable buffers with an off-heap pool. (Yea, I know we talked about that, and bear with me about the details of implementing such an efficient pool for now, let's simply agree that while it might be non trivial, it surely can be done. and it's not that hard considering you have a rather "stable" buffer size). So with the {{byte[]}} solution the memory cost of JVM heap usage would be * *A* {{(buffer_size + array_headers) * N}} With a simple wrapper option like I am re-proposing now this would result into (what you say is unacceptable): * *B* {{(~16 bytes + buffer_size + array_headers) * N}} My guess is you consider this unacceptable because N is often large? But then we'll agree that the {{buffer_size}} is more concerning than the ~16 bytes. But the ultimate solution looks like this: * *C* {{(~16 bytes + cost_of_pointers_to_mmapped_memory) * N}} Which imo looks much better as the overall cost is better predictable as it's not depending on the size of the objects being transmitted. Predictability is good, and {{N}} is probably not unbounded (I guess?) so that would allow people configuring it to make a clear decision on how much memory mapped space one wants to dedicate for this purpose. So while we can certainly agree that *B* is less efficient than *A*, the reason I'd change the interface nevertheless is that it can then allow us to move on to solution *C* at due time. And really, those 16bytes, I have a hard time believing they make all the difference: compared to the buffer size itself I suspect that's a negligible overhead. Not least, I believe the abstraction would make for a better internal API and integration points to either express reusage of buffers explicitly, or be able to perform some (optional?) validation for correct behaviour. -- This message was sent by Atlassian JIRA (v6.4.11#64026)