Analysis of a moderately-loaded local rib points to the fact that we could do a lot better where memory efficiency is concerned.

One notable area is the AbstractAdjRIBs$RIBEntry, which contains a 16-entry HashMap for candidates, typically costing us 176 bytes per entry. There is an upper cap as to how many entries that map can have, which is directly tied to the number of peers currently contributing to that particular table instance.

We can take advantage of this knowledge and maintain the candidates in a fixed-size array. The table instance will maintain Peer->offset mapping, reformatting entries as the configuration changes. Each entry will then contain a simple fixed array into which the appropriate attributes will be stored.

This can be used to also track outbound state, further improving efficiency of the entire solution. Be sure to factor those requirements in the solution.