DatagramChannel performance issue

[Martin Thompson]

On Mon, 27 Aug 2018 at 19:23, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 27/08/2018 14:47, Martin Thompson wrote:
> > :
> >
> > With the following signature we could implement better services.
> >
> >      /**
> >       * Receive a datagram payload with associated source address and port.
> >       *
> >       * @param source  bytes representing source address and port.
> >       * @param payload bytes for the datagram.
> >       * @return true if a datagram has been received in non-blocking mode.
> >       */
> >      boolean receive(ByteBuffer source, ByteBuffer payload);
> >
> > The source buffer could then be wrapped with a flyweight to extract
> > the source address and port to decide if a InetAddress and
> > InetSocketAddress need to be created, or extra methods applied to
> > InetAddress. For example:
> >
> >      boolean matches(ByteBuffer source)
> >
> >      InetAddress getByAddress(ByteBuffer source)
> >
> > Port can be stored directly after the address in the source buffer.
> >
> > This implementation could be utilised internally by the existing
> > receive implementation to make it more efficient and offered as a new
> > API so that UDP based services can be developed which are competitive
> > on performance with native implementations plus avoid unnecessary
> > allocation and JNI up calls.
> >
> The SocketAddress type would also need to be encoded into the source
> buffer if there were to an API like this. I think it would be better to
> start out by improving the implementation of the existing receive method
> to eliminate the need to construct objects or set fields in the JNI
> code. Is this something that you would like to contribute?

I'd be happy to help if I can. How do you think the existing method
can be improved? Would there need to be some sort of cache of address
objects to honour the existing receive API which returns an address?