To be done in Message unmarshalling and Message.setDest()/setSrc().

This will save us memory

[email from Bruce]
There's a recurring theme of memory bloat with STABLE and NAKACK. While these protocols, and controls like FC, let you control their memory footprint, it might help to analyse just how much each retained message is costing.

Using JProbe (or just reading the code), you can see that a message has three things contributing to its size: the payload, a ConcurrentReaderHashMap (message headers), and an IpAddress.

• I don't see how you could do much about the payload.
• You do need something to hold the headers - maybe there's something more compact than CRHM to hold them when unmarshaling a message in a receiving process? Are header sets updated in a received message?
• src_addr IpAddresses could be made canonical in Message

I haven't looked into the hashmap possibility yet, but you can easily shave some megabytes off a bloated pbcast.NAKACK by canonicalizing src_addr objects in Message. All you have to do is change the readExternal/readFrom methods to use a lookup table or canonicalization method

private static Map canonicalAddresses = new ConcurrentReaderHashMap();

/** canonicalize addresses to some extent. There are race conditions

• allowed in this method, so it may not fully canonicalize an address
• @param nonCanonicalAddress
• @return canonical representation of the address
  */
  private static Address canonicalAddress(Address nonCanonicalAddress)
  Unknown macro: { Address result = null; if (nonCanonicalAddress == null) { return null; } // do not synchronize between get/put on the canonical map to avoid cost of contention // this can allow multiple equivalent addresses to leak out, but it's worth the cost savings try { result = (Address)canonicalAddresses.get(nonCanonicalAddress); } catch (NullPointerException npe) { // no action needed } if (result == null) { result = nonCanonicalAddress; canonicalAddresses.put(nonCanonicalAddress, result); } return result; }