[infinispan-issues] [JBoss JIRA] (ISPN-4979) CacheStatusResponse map uses too much memory

[ https://issues.jboss.org/browse/ISPN-4979?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-4979: --------------------------------------- That's not exactly what I meant, sorry I've been too short as I simply meant to refer to "old discussions". We once discussed the need to not allocate new Address instance copies so often - I had diagnosed this as an allocation hot spot 2-3 years ago - and the discussion was about what kind of data structure we should use to represent a "View", and to use the View as a sort of root for most other collections we normally need for sets of addresses as these could be seen as a "mask" on top of the View they were linked to. I actually coded much of that but it was breaking too many SPIs as I was replaceing all instances of Collection<Address>, List<Address>, Set<Address>.. so the task was postponed and I think it would be a nightmare to try rebasing my old patch but I still think something in that league is eventually going to be necessary. The basic principle is that - besides some exceptional cases - a mask of the View is good enough to represent any such Set<Address> as even when you need ordering like in List<Address>, the ordering is always going to be the same and all lists also need the property of no-repeated instanced provided by the Set. So you need a custom data structure, which we can make very efficient as our requirements are simple. Also there are plenty of points in the code in which defensive collections are created, the representation I was experimenting with would be an immutable collection, which you could mask recursively.. so with no mutations, you could guarantee that no copy would be done unless there was an actual need for it, and even then each copy would be cheap as it's again just a mask and a pointer to the inner set. This wouldn't just be a custom collection, but you'd also have the "ViewManagementService" to be "the" only place where Address instances are maintained. If you had a de-serialization context, and the Unmarshaller had access to it, it could use it to incarnate references from the pool (as it is the pool). This would also make sure that you don't need to worry about cleanup of unused Address instances in the Unmarshaller cache, as nodes leaving would imply a View change and hence a cleanup from the root structure. -- This message was sent by Atlassian JIRA (v6.3.8#6338)