How to avoid memory reallocation in UDP receive

[David Daney]

P.O. Gaillard wrote:
> Hello,
> 
> I am looking at the gnu::java::net::PlainDatagramSocketImpl::receive 
> code because it allocates memory on the heap when it should not need to 
> (the Sun JDK does not seem to allocate on the heap with the same program).
> 
> The reason for the allocation seems to be that the IP address is stored 
> as an array and since the IP address may be 4 or 16 byte long (IPv6) the 
> code just reallocates the array to store the IP address every time a new 
> message is received.
> 
> I would like to avoid that and do the following :
>  1) check that an IP address with an byte array of the right size is 
> available
>  2) if not execute the current code (i.e. allocate an new InetAddress 
> instance and fill it with the data)
>  3) if there is an InetAddress instance that can be reused, update the 
> byte array.
> 
> It seems that I would need to modify InetAddress.java (add a 
> protected/private setAddress method) and PlainDatagramSocketImpl (use 
> the new method in InetAddress to update the address instead of 
> allocating a new one).
> 
> Of course, this might cause unwanted side-effects for programs that kept 
> a reference on the address found in the datagram instead of making a copy.
> 

This is the key.  We cannot be changing the public interfaces in libgcj 
in such a manner that the documented semantics break.

If you can devise a way to reduce memory consumption while maintaining 
the documented semantics, then we would welcome the change.

Since all the code is licensed under the GPL you are free to make any 
changes you wish for your own use, but changes to libgcj are generally 
only accepted if they further the goals of the project (creation of a 
JDK compatible system).

> So, I would like guidance from the GCJ folks :
> 1) does the change seem reasonable ?
> 2) could I submit a patch and to whom ?

Patches go to java-patches@gcc.gnu.org or classpath-patches@gnu.org 
depending on whether they are libgcj specific or part of the more 
generic classpath project.

You should probably also read this page:

http://gcc.gnu.org/contribute.html

for information on making contributions to gcj/libgcj.