I think it might be a good change BUT you didn't say how big was the benefit of this change on memory consumption. Could you tell us how much memory the JVM was using before and after the change under the same load?
Gaston Dombiak wrote:
Hey, We are opening 60K concurrent connections to Openfire and generating some heap dumps to analyze memory consumption. And we found something that really surprised us since we never heard about it. A very big part of the total memory is being consumed by ConcurrentHashMaps. The ConcurrentHashMap uses internal objects to keep track of its content and even if you have an "empty" ConcurrentHashMap the map will create as many segments as its default size. Tracing the references I see that BaseIoSession uses a ConcurrentHashMap to keep track of the session attributes. Based on this finding I made some changes to Openfire so that not highly concurrent code and heavily used code would use synchronized + HashMap (the old style we can say) instead of a ConcurrentHashMap. I don't see that MINA uses the session attributes and in the Openfire's case the usage of those attributes is high (but not that high) and never concurrent. So what do you think of changing BaseIoSession to use a HashMap and use synchronized block when accessing that variable? HashMap also uses internal objects but they are smaller and less objects. Regards, -- Gato
_________________________________________________________________ Få de bedste søgeresultater med MSN Search: http://search.msn.dk
