ты посмотрел как работает твой trie, заплакал и взял HashSet?

Как он работает я и так знаю (божественно). Но вот при compressed refs оно ест в два раза больше памяти чем HashSet.

потребление памяти - это одна из характеристик критерия "работает".
а чтоб сэкономить память, не пробовал реализовывать дерево на массиве из четырёхбайтовых беззнаковых? // хотя это скорость может убить.

У меня оно и так реализовано на одном contiguous массиве интов. Асимптотически стремится к 12 байтам на запись. Но очень медленно. На 2 миллионах айпишников тратит 79 байт на запись, а на 6 миллионах — 74 байта на запись

можно ещё в лоб жахнуть битмап на 512 метров. хотя это больше по памяти, но может работает быстрее?
ах да, на ipv6 такое взорвётся.
кстати что будет лучше для ipv6 - hashset или trie?

можно ещё в лоб жахнуть битмап на 512 метров

Можно. Проблема в том, что придётся дополнительные преобразования делать с Inet4Address, чтобы беззнаковый индекс получить и к тому же BitSet знаковый int принимает в качестве индекса при доступе к биту.

хотя это больше по памяти

HashSet при compressed refs занимает 400 МБ.
Trie занимает 800 МБ

но может работает быстрее?

С учётом преобразований и костылей описанных выше, это будет работать примерно с той же скоростью что и HashSet (у Inet4Address ебически хороший hashCode)

кстати что будет лучше для ipv6 - hashset или trie?

Однозначно HashSet

А trie я потом использую для задачи с которой HashSet справиться не может — поиск какой из заданных подсетей принадлежит айпишник.

не удивлюсь, если hashCode для Inet4Address просто возвращает значение адреса.

Именно это он и делает. И это максимально хороший хэшкод из тех что можно придумать